Raw scans: Part 3 Amendments and Part 4
I I ~ I ~ I I I ~ A I I ~J I ~ n ~ ~ STAN DARD 7816-3
First edition 1 989-09- 1 5
AMENDMENT 1 1992-12-~1
Identification cards - Integrated circuit(s) cards with contacts
Part 3 : Electronic siqnals and transmission protocols
AMENDMENT 1: Protocol type T = 1, asynchronous half duplex block transm ission protocol
Cartes d'identification - Cartes a circuit(s) integre(sJ a contacts Partie 3: Signaux electroniques et protocoles de transmission
AMENDEMENT 1: Type de protocole T = 1, protocole de tranSmiS5iOn par blocs half-duplex asynchrone
Rnproduccd B~ GLOBAL ENGINEERING DOCU~IENTS Wilh The Permislbn of 150 Undcr Rq~ A~mnnt Reference number ISO/IEC 7816-3:1989/Amd.1:1992 IE)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and nongovernmental, in liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee. ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an Intemational Standard requires approval by at least 75 % of the national bodies castinq a vote.
Amendment 1 to International Standard ISO/IEC 7816-3:1989 was prepared by Joifit Technical Committee ISO/IEC JTC 1, Information technology.
ISO/IEC 7816-3 consists of the following parts, under the general title Identification cards - Integrated circuit~sJ cards with contacts
-Part 1: Physical charactenstics -Part 2: Dimensions and location of the contacts -Part 3: Electronic signals and transmission protocols
Annex A of this amendment to ISOAEC 7816-3 is for information only.
~ISO/IEC 1992
All ri~hts reserved. No part of this publication may be reproduced or utili~ed in any form or by any means, electronic or mechanical, includin~ photocopyin~ and microfilm, without permission in wrnin~ from the publisher.
Internaoonal Or~anization for Standardization Case postale 56 . C~1211 Geneve 20 . Switzerland Printed in Switzerland
Identification cards- Integrated circuit(s) cards with contacts
Part 3 : Electronic signals and transmission protocols
AMENDMENT 1: Protocol type T = 1, asynchronous half duplex block transmission protocol
Replace the existing clause 9 and add a new annex A as follows:
9 Protocol lype T=1, asynchronous half duplex block transmission protocol
This Iransmlsslon protocol is defined as tne protocol type T=1 in a TD, byte ot the Answer-to-Rese; (see 6.1.4.3). Thls clause defines the structure and processlng of commands for transmisslon control ana for IC carri speclflc control in an asynchronous half dupiex block transmlssion protocol. These commands may be Innlated either by the intPrf:~r.P ~iQVI('~ ' the card
The maln charactenstlcs of the block transmisslon protocol are the followlng.
a) A block is the smallest data unit which can be transmnted between an IC card ~ICC) and an interface devlce (IFD).
A block may be used to convey
(1) appllcatlon data whlch is transparent to the transmlsslon protocol;
(2) transmlsslon control data Including transm,ss~on error handllng, (see 9.1 )
b) The deflnnlon of the block structure allows the correct receptlon of the whole blocK to be checked betore processlnq the data conveyed ~y the block.
c) The Identlllcaeon o1 a block !recognlzlng the start and the end cf a block) IS handled in the cnaracter component o' ~he data llnK layer
d) I he protocol stans enner after the answer to reset or the protocol type selectlon (pTs) (clause 7) wlth a ~Irst block sent by the IFD an~ contlnues wnh alternatlng nght ~o send a biock.
Thls protocol uses the character frame deflned in the answer to reset and the physlcal parameters defined by the global Interface bytes (see 6.1.4.4) unless modified by the protocol type selectlon. Thls clause covers the frame structure o~ a block and organlzatlon of
Data transmlsslon control such as flow control, block chalnlng. ans error correctlon
Speclflc Interface control
This protocol is designed according to the principle of layenng of the OSI reference model, wrth partlcular attention to the mlnimlzatlon of interactions across boundanes. Three layers are defined:
The physical laver exchanges brts according to 6.1
The data link laver is defined by the character component and block component. The character component exchanges characters according to 6.1.2. The character repetnion and error signalllng described in 6.1.3 shall not be used, so that the minimum delay between two consecutive characters may be recfuced to 11 etu, according to the interface character TC1. The block component exchanges blocks dehned in 9.6.2.
The apPIication laver processes commands, which involves the exchange of at least one block or chain o~ blocks in each direction.
9.1 Definitions and abbreviations
9.1.1 Definitions
For the purposes of thls part of ISO IE~, 7816. the followlng deflnitions apply to clause 9.
9.1.1.1 block: A successlon of characters compnslng two or three fields deflnea as prologue fleldmnformatlon fleld and epilogue field.
9.1.1.2 destination node address; DAD: The portlon of the subfleld noae address (NAC)I wnlch IS usea to laentlfy the Intenaed recelver ot the block
9.1.1.3 epilogue tield: The tinal field of a block. It contalns the error detectlon code (EDC) byte(s)
9.1.1.4 error detection code: EDC: The result of an error checking method, applled to all characters In the prologue field and In the Informatlon fleld !1 IS transmnted In the epilogue field.
9.1.1.5 field: One of the three components of the block definea as prologue, informatlon or epllogue.
9.1.1.6 information block; I-block: A block whose prlmary purpose IS to transmn appllcatlon layer Informatlon.
9.1.1.7 information field; INF: The field of a block which contains data (generally appllcatlon ~ata~
9.1.1.8 length; LEN: A subfleld ot the prologue fleld. It contalns the number ot bytes transmnted In the Intormatlon fl~ld ntth~ hln~k
9.1.1.9 node address; NAD: A subtleld ot the prologue fleld. It Indlcates both destlnatlon and source node addresses ot the block and VPP state control.
9.1.1.10 prologue field: The tlrst tleld of a block. It contalns subtlelds tor node address (NAD), protocol control bYte (PCB) and lenqth (LEN)
9.1.1.11 protocol control byte; PCB: A subfleld ot the prologue tield. It contalns transmlsslon control Informa~lon.
9.1.1.12 receive ready block; R-block: A block whlch contalns posnive or negatlve acknowleagements. It contalns the block number of the expected l-block.
9,1,1.13 source node address; SAD: The portlon of the subfield node address (NAD) whlch IS used to Identlfy the sender of the block
9,1,1,14 subfield: A functional component of a field.
9,1.1.15 sup,ervisory block; S-block: A block which contalns transmission control informatlon.
9.1.1,16 transmission control: A function used to control the data transmission between the interface device (IFD) and the IC card (ICC). It includes VPP state control, block transmission with sequence control, synchronization, and recovery of transmlsslon errors.
9.1.2 Abbreviations
BGT Block guardtlme BWI Block wanlng tlme Integer BWT Block waltlng tlme CRC Cyclic redunaancy check Character waltlng tlme Integer Character warting tlme DAD Destlnatlon node address EDC Error ~etectlon coae l-block Informatlor; block ICC Integrated circuit(s) card. IC card IFD Interface device IFS Informatlon field slze IFSC Informatlon fleld slze for tne card IFSD Informatlon fleld slze tor the Interface devlce
CWI CWT
IFSI Informatlon field slze Integer INF Information fle,d LEN Length LRC Longltudlnal redundancy chec~ NAD Node address OSI Open systems Interconnectlon PCB Protocol control byte R-block Recelve ready biock R Receive ready SAD Source ncde address S-block Supervisory block WTX Waiting tlme extenslon XOR Excluslve-OR
9.2 Character trame
The character frame IS as defined for the answer to reset In 6.1 2 and 6.1 4 4 (last paragraph) unless modifled by PTS In 7.2 (5th paragraph).
Parny checking may be used In additlon to EDC (see 9.4.3) to determlne the valldlty of a block
9.3 Block trame A block IS a serles of characters (9.2) contalnlng data bytes (as deflnea Ir 6 -prologue fleld !mandatory~ -informallon fleld (optlona -epllogue flel~ (manaatory as shown In flqure 9 .2, A block conslsts of the followlng flelds
Prologue Field Information Field Epilogue Field Node Protocol Length (see 94 2) Error aetectlon address control code LRC or CRC NAD PCB LEN INF EDC 1 byte 1 ~vte 1 byte O to 254 bytes 1 or 2 bytes
L~ length Error detection code Figure 9 - Block Structure
9.4 Basic elements ot tne t~lock 9.4.1 Prologue tield
This field is mandatory and conslsts of three bytes: the node address, the protocol control byte and the length.
9.4.1.1 Node address (~AD)
The node address (NAD~ is a byte used to identify the source and the intended destlnatlon of the block. N~D may be u-ed to dlslingulsh between multlple ioglcal connections when thev coex~sl.
The bns b1 to b3 indlcale the source node address SAD and the blts b5 to b7 indicate the destlnation node address DAD. The blts b4 and b8 are used for VPP state control (see 9.6.1.1).
The NAD of the first block sent by the IFD shall establish the assoclatlon of the address~s SAD and DAD by which a loglcal connectlon Is deflned. Subsequent blocks In which the NAD fleld contalns the same SAD DAD address palr are assoclated wnh the same loglcal connectlon. Other loqlcal ccnnectlons du ing ~he subsequent Inforrrat,o,, exchange may be slmllanly deflned by other SAD, DAD palrs.
NOTE - For e~(ample blocks sent by the IFD wlth the values XD as SAD and y~ as DAD and blochs sen~ by tne ICC wlth the values x~=YD and y =x, belong to one loglcal connecoon - denoted by (x,y~ wnereas blochs senl by the IFD wnh vc as SAD and WD as DAD and DIOckS sent by the ICC wlth the values v =wD ana w~=v~ Delong o a second loglcal connecDon (v wJ
When the addresslng IS not used. the values ci SAD and DAD are sel lo 0. Any other node addresses where SAD and DAD are Identlcal are reserved for future use.
9.4.1.2 Protocol control byte ~PCB)
The protocol control byte IS used to convey the Information requlred to control data transmlsslon.
There are three fundamental types of blocks defined by Ihe prolocol:
An Informatlon block (I-block) IS used to convey Intormation for use by the appllcatlon layer. In additlon, it conveys a posltlve or negatlve achnowledgement.
A receive readv block (R-block) is used to convey pOSnlve or neqatlve acknowledgements; ns informatlon field shall not be present.
-A supervisorv block (S-block) IS used to exchanqe control Informatlon between the IFD and the ICC: ns information field may be present depending on Its controlllnq functlon.
NOTE - Thls separaaon allows the deslgn ot the protocol control and the appllcaDon ponlons ot the d~v~e mcrocode to be relatlvelv Independent ot one another
The PCB defines whether a block is an l-block, an R-block, or an S-block. For PCB codinq details see 9.6.2.4.
9.4.1.3 Lenglh (LcNj
LEN Indlcates the n~mber of bytes transmltted In the informatlon field of the Dlock (see also 9.5. 1).
The coding shall be
00 to FE codes the number of bytes In the Informatlon field from 0 tc 254.
FF is reserved for future use 9.4.2 Intorma~ion field (INF)
The presence of INF is optional. When present. .'.F conveys either applicatlon data in l-blocks or non application control and status Informatlon In S-blocks. The number of bytes transmltted is Indlcatea by LEN
9.4.3 Epilogue field
This field is mandatory It contalns the error detectlon code (EDC) of the transmltted block.
The protocol deflnltion permits thls io ~e ei;har an
(longltudlnal redundancy check), or a CRC ~c. redundancy check). The LRC Is one byte In length, wnlle the CRC is two bytes. The LRC is calculated as the exclusive OR (XOR! of all the bytes startlng with the NAD through the last byte of the Informatlon field, and is typically referred to slmply as the checksum. For CRC see ISO 3309.
9.~ Specitic interface parameters
In the Answer-to-Reset, the SDeCIflc Interface characters for T=1 are Indlcatea sIartlng wlth TA, (1>2
9.5.1 Information field sizes (IFS) 9.5.1.1 Intormation field size for the card (IFSC)
IFSC is the maxlmum length of informatlon field of blocks which can be received by the card. The initial value of IFSC is given by IFSI in the speclflc Interface character TA (i,2). The detault value is 32.
The codlng shall be
'00' is reserved for future use. 01 to 'FE' codes values for IFSC Irom 1 to 254. 'FF' is reserved for future use.
NOTE The bloch see lS the tolal number of all byles transmlned In Ihe prologue, Intormaoon, and epllogue helds The maxlmum bloch size IS equal to IFSC plus 4 or 5 ~dependmg upon the length o~ the epdogue held).
9.5.1.2 Information tield size for the interface device (IFSD)
IFSD is the maximum length of the information field for blocks which can be received by the interface device. The initial value is defined as 32.
~he coding shall be 35 for IFSC in 9.5.1.1.
9.5.2 Waiting times
9.~.2.1 Character waiting time (CWT~)
The character waltlng tlme (cwTt Is oe!lned as the maxlmum tlme between the leaalng e~ges of two consecutlve characters In the same DIOCK. See flgure 10.
The least slgnificant half by~e (b4 lo ~1~ of TB (i,2) coces the character waltlng tlme integer CWI so that CWT is calculated by
CWT = (2~W + 11 ) wor~ etu
Therefore the mlnlmum value of CWT is equal to 12 work etu. See 6.1.4 4 aefln~t~on ol work etu.
Character Next character 11, ,1 11, 1III1 t < CWT ~|
Figure 10 - Character waiting time (CW~T) The oefaul~ value of CWI Is 13.
NO, t When ~he~e ,s a wlentlal erro- In the lenglh the CWT may ~e user~ bv tne ~ecelvlno noae tO r~etP~t tllf~ e nr~ r~t
9.5.2.2 Block waiting tlme (BWT)
The Block wanlng tlme ~BWT~ IS deflned as the maxlmum tlme Delween the leadlng eclges of the last cnaracter wh~cn gave the ,,gnt to sena to the card and the tlrst character to be sent Dy the card See flgure 11
The most slgnlflcant half byte (b8 to D5i of TB ~1>2) codes the block wanlng tlme Integer BWI so that BWT is calculated by
BWT = 2~w x 960 x 372!fs s + 11 work etu for an external clock card
BWT = 2~W !10 s + 11 work etu for an Internal clock card
where 0--BWI-9 and BWI>9 is reserved for future use.
f-s~ ola~acl-l ol ~ norl o~ o~ r~ ICC
1 I
BGT . I . BWT ù~
Figure 11 - Block guardtime (BGT) and block waiting time (BWT)
The default value of BWI is 4.
The block waning tlme is used to detect an unresponsive card.
9.5.2.3 Block guardtime (BGT)
The block ouardtlme (BGTi IS aeflnea as the mlnlmum tlme between tne leaolna eaaes of two consecutlve characters sent In opposlte olrectlons. Consequently tne oelay between the last cnaracter of a recelved block and the flrs; cnaracter of a transmltte~ blocK snall be at least BGT but less than BWT. See flaure 11
The vaiue of BGT shall be 22 WOrK et,J 9.5.3 Indication of protocol options
The specific interface character TC (1>2) Indlcates the form of the error detectlon cooe by
bn b1 = 1 Use of CRC = O Use of LRC (default valuel
Bits b2 to b8 are reserved lO? future use and shall be set to 0.
9.6 Protocol operation 9.6.1 Data link layer - Character component 9.6.1.1 VPP control
The state ol VPP Is controlled Dy ~ns b8 and b4 of the NAD byte sent by the cara, ana by the PCB character whlch immediately follows. Bns b8 and b4 of NAD deslgnate
b8=0. b4=0 requlres VPP to be returned to or kept In Idle state
b8=1, b4=0 requires settlng the actlve state of VPP. VPP IS returneo to Idle state on recelpt of the Pf~ R
b8=0, b4=1 requlres settlng the active state of VPP untll receptlon of another NAD byte by the interface devlce. b8=1~ b4=1 is forbldden.
If a panty error occurs on the NAD. VPP is returned to or kept in idle state.
If a tlme-out occurs, i.e. if the card lails to send an expected character withln CWT or BWT, VPP is returned to or kept In idle state.
All transnlons on VPP tnggered by a character shall occur wnhin 12 etus from the leadlng eage of thls character. 9.6.1.2 Error-tree operalion
After answer to reset with or wnhout protocol type selection, the Interface devlce has the right to send. This is consldered to be the beglnning of the block transmlssion protocol. When protocol T=1 has been designated an Interface device sends only blocks.
When e~ther the ICC or IFD has sent a complete block. it swltches to receiving state. When elther the ICC or IFD has received the number of characters in accordance with the length subfield, it assumes that it has the right to send.
9.6.2 Data link layer - Block component
In the procedure description the following notaaon will be used.
9,6.2.1 Notation (see 9.4.1.2)
The followlng notatlons are used to identify terms used In the descnptlons of how the protocol functlons.
I-b!ocks are denoted by
I(N(S),M) N(S) Is the send sequence number and M
IS the more data bn (see 9.6.2.2.2).
N;(S),NDjS) To distlngulsh the seo,uence numbers sent by sources A or B the Indices a and b are added to N(S)
R-blocks are oenoted by
R(N(R)) R-block Indlcating receive ready (R), and N(Ri. N(R) Is the block numDer of the next message the recelver expects to recelv
S-blocks are denoted by
S(RESYNCH request) S-block Indlcatlng RESYNCH request
S(RESYNCi~ response) S-block indlcatlng RESYNCH response
S(IFS requesl) S-block indlcatlng IFS offer S()FS respOnsel S-block indicating IFS offer achnowledgement S(ABORT request) S-block indicatlng ABORT request S(ABORT response) S-block indlcating ABORT response S(WTX requestl S-block Indlcatlng WTX request
S(WTX response) S-block Indicatlng WTX response
S(Vpp error response) S-block sent by the IFD to Inform the card of a Vpp error
The S-blocks S(IFS...) and S(WTX...) contain INF, whose coding IS defined by rules 3 and 4 in 9.6.2.2.3.
9.6.2.2 Error-tree operation
9,6.2.2.1 General procedures ~see 9.4.1.2)
The tirst block transmnted by the IFD to the ICC aher the answer to reset or after the protocol type selectlon, shall be enher an l-block or an S- block.
After a block (I-, R- or S-bloch) has been sent, an acknowledgement shall be received before start of the transmlssion of the next block, as described in the following.
An i-rbiock carries iis send se~uence number N(S N(S) consists of one blt ana Is counted moaulo 2 Its value starts wnh N(S)=0 elther after the stan of the block transmlsslon protocol or after resynchronlzatlon ana Is Incrementea atter sendlnr1 each l-block.
The numbers N(S) of l-blocKs sent ~y the IFD and ot tnose sent by the ICC are countea Inaepenaently from each other. Acknowledgement of a transmltted l-block Is indlcated when N(S) of the next recelvea l-block Is dlfferent from N(S) of the prevlously recelved l-block.
An R-block carnes N(R), whlch Is the value of N(S) in the next expected l-block. Acknowledgement of an l-block is indicated when the N(R) of the recelved next R-block Is different from the N(S) of the sent l-block (see 9.6.2.2.3, Rule 2.2).
In errorfree operation R-blocks are used for chalnlng (see 9.6.2.2.2).
An S-block carries no number. An S(... request)-block carnes no acknowiedgement An S( response~-biock acknowledges the recelved S( . request)-block
9.6.2.2,2 Chaining
Chaining is a function of the Dlock transmlsslon protocol. It allows the IFD or ICC to transmlt Informatlon (appllcatlon aata) longer than IFSC or IFSD.
If the IFD or ICC has to transmn informatlon longer than IFSC or IFSD respectively, it should dlvlde the intormatlon into blocks. each wlth LEN less than or equal to IFSC or IFSD, and send Ihe multiple blocks uslng chainlng function.
The chaining of blocks Is controlled by the M-bit ("More data bit") in the PCB of an l-block. The M-bn Indicates two states of an l-block:
O = last block of chaln 1 = chalned data follows In subsequent block(s)
Figure 12 illustrates the chalnlng functlon.
. Appllc I atlon I Data IS transmltted by , ~PI APPIIC |E~ |PIabOn |E~ ~ Data |E~
IFD 1(0.1 ) I(l 1 ) 1(0.0
P = Prologue E = Epllogue R(1 ) R(0) 1(0.0) Figure 12 - Chaining function
When the receiver receives a More data l-block correctly. it shall send R(N(R))~ where N(R) is equal to N(S) of the next l-block.
NOTE - I-blochs with LEN=0 may be used within a chain (see scenano In A 14.3~
9.6.2.2.3 Protocol rules for the error-tree operation
Rule 1: The Interface device sends the first block: elthe an i-block with N(S3=0 and M (More aala blt~, aeslgnated as 1(0,M), or an S-blocK
Rule 2.1: I(Na(S) 0) sent by A
is acknowiedged by l(ND(S),M) sent by ~
to transmlt appl~catlon data and to Indlcale r~ine~s to recelve tne next l-bloc~ from A.
Ru!e 2.2: I(Na(S),1) sent by A is acknowledged by R(N~,(R)) sent by B [where ND(R) is not equal to
Na(S)] IO Indlcate that the recelved biock was correct
and the readlness to recelve the next l-bloc~ fr ~ A
NGTE Chalnlng 15 only posslble In one d~rectlon at a ome
Rule 3: l~ the ICC re~ e- more than ~WT to process the prevlously recelved l-blGck, It senas s(wTx reouest, where INF IS a one ~yte blnary Integer multl~lle~ o~ the BWT value. The IFD acKnowlecges by S~WTX response) wlth the same Il~lF
The time allocated stans at the leaalng eage oi tne last cnaracter o~ the S(wTx response) ~lock
Rule 4: The ICD sends S(IFS request) to Indlcate a new IFSC n can support and thls shall be acknowle~ged by S(lFs response) wnh the same INF. ~he IFD assumes the new IFSC is valid as long as no other IFSC is Indlcated by another S( I FS reouest 1
The IFD sends S(IFS request) to Indlcate a new IFSD It can suppon and thls shall be acknowleoged by S(IFS response~ wnh the same INF The ICC assumes the new IFSD IS valld as long as no other IFSD IS Indlcated by another S(lFs request).
IFSC and IFSD are each coded as a byte blnary Integer In the INF ot these S-blocks.
Rule 5: Chainlng IS Indicated by the M-bit, wnere l(N(S),0) IS a non chalned block or the last block ot a chaln. I(N(S!, 1 ) Is pan ot a cnaln and will be tollowed by at leasl one chalned bloch.
R(N(R)) requests transmisslon ot the next chalned l-block l(N(S)=N(R),...) and acknowledges the recelved chalned l-block l(NOT N(R),1).
9.6.2.3 Error handling 9.6.2.3.1 Errors detected by the receiver of a block
The tasks of the block layer are to transmn blocKs. t_ aetect transmission and sequence errors. to hanale s~Jcr errors and to resynchronlze tne bioc~ transmlsslon Drotoco. Therefore the protocol ot the CIOCK layer snould be a~ie to nandle the followlng errors
-BWT timeout: The delay between the ieadlng eage ot the last character o' a block and the leablng eage of tne flrst cnaracter ot the next block exceeds BWT. -Receptlon of an invalld bloc~ Examples are
a) a parity error In one or more characters of a block or an EDC error b) invalid PCB (due to unknown encoding):
c) Invalid LEN (transmlsslon error or Incompatlblllty wlth IFSC or IFSDn
d) loss of synchronlzatlon (enher an underrun when the recelver expects more than the numDer of recelved characters or an overrun when tne sender senas more characters than the value Indlcated In the recelved lenqth fiela):
el failure to recelve S( resDonse) aner havlng sent the relevan~ S(.. requesu
Resynchronlzatlon In thls protocol lS attempted at three consecutlve levels ll one levem s unsuccesstul, then the next level IS trled. The three synchronlzatlon levels are for the I FD
a) Retransmlsslon of blocks b) Use of S(RESYNCH request) c) Resettlng or aeactlvatlon of the ICC for the ICC
a) Retransmlsslon of blocks b) Use of S(RESYNCH response) c) Without action by the IFD, the card becomes unresponslve
9.6,2 3.2 Protocol rules for the error handling
Rule 6: S~RESYNCH request) may be sent only by the IFD to reach resynchronlzatlon and to inniate resetting the communlcatlon parameters of the block transmission protocol to its initlal values.
Rule 6.1: If a loss of synchronization 15 detected by the recelver, the recelver gets back the nght to send after a sllence on l/O greater than the larger of CWT or BGT
Rule 6.2: S(RESYNCH request) shall be responded to by S(RESYNCH response) from'the ICC.
Rule 6.3: Atter the IFD has recelved S(RESYNCH response), the protocol IS lnltlated
Rule 6.4: After the iFD has talied a maxlmum of three times in succession to reacn the intenaed resynchronization by sending S(RESYNCH request), it resets the ICC.
Rule 6.5: When an S(RESYNCH request) is recelved. the previously sent block is assumed not to have been received.
Rule 7.1: When an l-block was sent and an invalid block is recelved or a BWT tlmeout (with the IFD) occurs, an R-block is sent, wh~ch re~uests with ns ~(R) for the expected l-block wrth l~(S)=N(R).
Rule 7.2: When an R-block was sent and an invalid block 15 received or a BWT tlmeoun (wnh the IFD) occurs. thls R-block is retransmnted.
Rule 7.3: When an S(... request)-block was sent and the recelved answer Is not S(... response)-block or a BWT tlmeout occurs (only IFD), the S!. reauest~-~lock Is retransmnted.
When an S(... response)-block was sent an~ an InValld D10Ck IS reCelVed or a BWT tlmeout occurs (only IFD), an R-block IS sent.
Rule 7 4.1~ After faillng to recelve an error free block at tne begmnlng of the protocol, the IFD maKes a maxlmum of two further anempts In successlon before resettlng or deactlvating the ICC.
Rule 7.4.2: Durlng the protocol, if the IFD fails to recelve an error free block n mahes a maxlmum of two further anempts In successlon before sendlng S~ESV~.,H request).
Rule 7 4.3: If the ICC fails to recelve an error free block after a second attempt In successlon, n remalns In recelve mode.
Rule 7 5: After the beglnning of the protocol the ICC reacts on receivlng an invalid first block by sendlng
R(0 ) .
Rule 7.6: If the first block sent by the IFD is not responded to wnhln BWT, the IFD sends R(0).
Rule 8: When the ICC sends S(IFS request) and recelves an invalid block, it retransmits a maximum of one more S(IFS reauesl) block In order to elicit an S(~FS res~onse). After the second failure n rernains in receive mode
Rule 9: The abon~on o1 a chaln can be innlated by either the sender or receiver of a chaln sending an S(ABORT request).
The S(ABORT request) shall be answered by an S(ABORT response), after which an R-block may be sent de,oending on whether it is necessary to aive back the riaht to send.
NOTE - Abortlon ot chamlng may be due to physical erromn the ICC. such as ICC memor~ error
O ~: O A ~'~ir~ A~ Drt~ 9.6.2.4.1 PCB of l-blocks
In all l-blocks the most slgnlflcant bn ~b8) o~ tne PCB IS set to zero.
The other 7 bits are used as snown In flqure 13.
o' I-olor ~s
L~ ~eserver. Reservr c Rese veo ~ese vec Rese~ veo Mo~e oa:a Dl' M Seno Sea~ence nur-loe N(Si
Figure 13 - Coding of l-block PCB
Bits b1 to b5 are reserved for future use and shall be set to zero.
9.6.2.4.2 PCB of R-blocks
In all R-blocks the most slgniflcant blt (b8) of PCB is set to one and the bit b7 of PCB IS set to zero.
The other 6 bits are used as shown In flgure 14. O Ni~l) 0 0 0 0 O N(R) O O O ø WFRI ø O 1 0 t~lr~r V:~IIIOC r~c~v~l PC5 o~ Rblocks Error~ree EDC or panty erTor Olher errors
Figure 14 - Coding ot R-block PCB
NOTE The value ot N(R) states whether the R-blocK Is an error Indlcatlng blor;k or not Blts b1 to b4 may optlonally be evaluated
9.6.2.4.3 PCB of S-blocks
In all S-blocks both the most slgniflcant bRs (b8 and b7) of PCB are set to one.
The other 6 blts are LJsed as shown In flgure 15.
PCE ol R blor ks ~D6 ~s rns RESF~NSE Dll)
o o o o O C RESYNCH rr,~qur~sl
O O O O O RESYNC~ rrJsrJons0
o o o O o 1 IES roouusl
0 O O O 1 IFS rr,~sCons0
o o o o 1 o A00RT r~sl
O o 0 1 ø Ar~oRT rr~Soonso
o O C 0 1 1 WTX r~lowsl
0 0 0 1 1 WTX rowonse
o o 1 o o vr~o error rosoonse
~all o~ r v~ues r~rs~rvr~
Figure 15 - Coding of S-block PCB
9.6.2.2.3 Protocol rules tor the error-free operation
Rule 1: The interface devlce sends the first block: eithe~ an l-block wlth N(S)=O ana M (More oata ~It), designatea as 1~0,M), or an S-bloc~.
Rule Z.1: I(Na(S) 0) sent by A
is acknowiedged by l(N,,(S),M, sent by B
to transmlt appllCatlon dala and to Indicate reaalness to recelve tne next l-blocK from A.
Ru!e 2.2: I(Na(S),1) sent by A is acknowledged by R(N,,(R)) sent by B [where ND(R) is not equal to
Na(S)]
to Indlcate that the recelved biock was correct and the readlness to recelve the next l-block jrorn A
I~OTE Chalnlng IS onty posslble In one dlrr~ctlon at a tlme Rule 3: Rule 4
If the ICC rea.,,~e- rnore than BWT to process the prevlously recelved l-bloc~, n senos SIWTX reouestl where INF is a one ~yle blnary Integer multlpller of the BWT value. The IFD acKnowleages ~y S~WTX response) wlth the same l~
T~le lime allocated stans at the leadlng eage of the last cnaracter of the S(wTx response~ ~lock.
The ICC sends S(IFS request) to Indlcate a new IFSC n can support and thls shall be acknowledged by S(IFS response) wnh the same INF. The IFD assumes the new IFSC is valld as long as no other IFSC is Indlcated by another S(lFs request~.
The IFG sends S(IFS request! to Indlcate a new IFSD rt can supPon and thls shall be acknowleaged by S(IFS response~ wlth the same INF The ICC assumes the new IFSD IS valld as long as no other IFSD is Indlcated by another S(IFS request).
IFSC and IFSD are each coded as a byte blnary Integer In the INF of these S-blocks.
Rule 5: Chaining IS Indicated by the M-bit, where l(N(S),0) Is a non chalned bloch or t~e last block ot a chaln. I(N(S~ s pan of a cnaln and will be followed by at least one chalned block.
R(N(R)) requests transmisslon of the next chamed l-block l(N(S)=N(R),...) and acknowledges the received chalned l-block l(NOT N(R),1).
9.6.2.3 Error handling 9.6.2.3.1 Errors detected by the receiver of a block
The tasKs of the block layer are to transmn ~IOC~(S. to detec~ transmisslon and sequence errors. to handle sucr, errors and to resynchronlze tne bioc~ transmlsslon orotocol Therefore the protocol of the DIOCK layer should be aDie to handle the followlng errors
-BWT tlmeout: The delay between the ieadlng edge of the last character of a block and the leadlng eclge of the tlrst cnaracter ot the next block exceeds BWT
-Receptlon of an invalld bloc~. Examples are
a) a parity error In one or more characters of a block or an EDC error
b) invaiid PCB (due to unKnown encodlng):
c) invalid LEN (transmlsslon error or Incompatlbllny wlth IFSC or IFSD);
d) loss of synchronlzatlon (enher an underrun when the recelver expects more than the numDer of recelved characters or an overrun when the sender sencts more characters than the value Indlcated In the recelved length flelc):
e) fallure to recelve S~ resDonse) after havlng sent the relevant S(.. request,
Resynchronlzatlon In thls protocol IS attempted at three consecutlve levels l~ one level IS unsuccessful, then the next level IS tned.
The three synchronlzatlon levels are for the IFD
a) Retransmlsslon of blocks b) Use of S(RESYNCH request) c) Resettlng or aeactlvatlon of the )CC for the ICC
a) Retransmlsslon of blochs b~ Use of S(RESYNCH response) c) Wnhout actlon Dy the IFD, the card becomes unresponslve
9.6.2.3.2 Protocol rules tor the error handling
Rule 6: S(RESYNCH request) may be sent only by the !FD to reach resynchronlzatlon and to initiate resetting the communlcatlon parameters of the block transmission protocol to its init~al values.
Rule 6.1: If a loss of synchronlzation Is detected by the recelver, the recelver gets back the nght to send after a sllence on l/O greater than the larger of CWT or BGT.
Rule 6.2: S(RESYNCH request) shall be responded to by S(RESYNCH response) from the ICC.
Rule 6.3: After the IFD has recelved S(RESYNCH response), the protocol IS Inlllated.
Rule 6.4 Atter the IFD has tailed a maximum of three times In succession to reach the intenaed resynchronization by sendine S(RESYNCH request), it resets the ICC
Rule 6.5: When an S(RESYNCH request) is recelved. the previously sent block Is assumed not to have been received.
Rule 7.1: When an l-block was sent and an invalid block is recelved or a 3WT tlmeout (with the IFD) occurs, an R-block is sent, whlch requests wi~h It5 I~I(R) for the expected l-block wnh Nts!=N(R).
Rule 7.2: When an R-block was sent and an Invalid block is received or a 9WT llmeout (wlth the IFD occurs, thls R-block is retransmntea.
Rule 7.3: When an S(... request)-block was sent and the recelved answer IS not S(... response)-block or a BWT timeout occurs (only IFD), the S! request~-~lock IS retransmnted.
When an S(... response)-block was sent and an Invalld block IS recelved Or a BWT tlmeou occurs (only IFD), an R-bloch IS sent
Rule 7.4.1 ~ After taillng to recelve an error ~ree block at the beglnnmg ot the protocol, the IFD makes a maxlmum ot two further attempts In successlon betore resetting or deactlvating the ICC
Rule 7.4.2: Durlng the protocol, it the IFD ~ails to recelve an error free block it mahes a maxlmum o~ two turther anempts In successlon beiore sendlns SiRESY~,H request).
Rule 7.4.3. I~ the ICC tails to recelve an error tree block atter a second attempt In successlon, It remalns In recelve mode.
Rule 7 5: Atter the beglnning of the protocol the ICC reacts on receivlng an Invalid first block by sendlng R(0).
Rule 7.6: If the ~irst block sent by the IFD Is not responded to wnh~n BWT, the IFD sends R(0).
Rule 8: When the ICC sends S(IFS request) and receives an invalid block, n retransmits a maximum of one more S(IFS request) block In order to elicit an S(lFs respon5eJ. After the seoond tailure it rernarns in receive mo~P
Rule 9: The abortion of a chaln can be innlated by either the sender or receiver of a chaln sending an S(ABORT request).
The S(ABORT request) shall be answered by an S(ABORT response), atter which an R-block may be sent depending on whether it is necessary to glve back the right to send.
NOTE - Abortlon of chammg may be due to physical error In rhe ICC, such as ICC memory error.
9.6.2.4 Codlng ot PCB 9.6.2.4.1 PCB ot l-blocks
In all l-blocks the most slgniflcant blt (b8) ol the PCB IS set to zero.
The other 7 bits are used as snown In figure 13.
D~ _ o' I-Dlocl'ls
L~ Reser~e~ Rese vec Rese vec hese~veo Rese~veo Mo~e oa:a o Seno Se~ue~ce n, N(S)
Figure 13 - Coding ot l-block PCB
Bits b1 to b5 are reserved for future use and shall be set to zero.
9.6.2.4.2 PCB of R-blocks
In all R-blocks the most slgniflcant bn (b8) of PCB is set to one and the bit b7 of PCB lS set to zero.
The other 6 bits are used as shown In flgure 14.
O b6 bS D4, b3 b2 bl O N~Ri 0 0 0 0 O N(R) 0 O 0 ø NfRI 0 0 1 o (all other values ~esevedl PCB ol Rblochs Errortree EDC o, pan~y error Other errors Figure 14 - Coding ot R-block PCB The value ot N(R) states whether the R block Is an error NOTE Indlcatlng DIOch o, not ~Its Dl tO D4 may opllonany De evalualea 9.6.2.4.3 PCB ot S-blocks
In all S-blocks both the most slgnlticant blts (b8 and b7) ot PCB are set to one.
The other 6 bl~s are used as shown In tl~ure 15.
D ~ oJ, b2 I Dl | PCE o~ F-Dlorl(s
(D6 ~s 1ne r~ESr'
o o o o o
o o o o
o o o o o
o o o o
o o o o
o o o
o o o
o o o
R E SYNC H reouesl RESYNC~ resr~onse IFS reoueel IFS resr~onse U ASOR7 nctuesl ø AE~ORT response wrx reo,uesl WT~ response
o o 1 o o vpp error response ~.1l otn~r v.l~s reservrJo)
Figure 15 - Coding ot Sblock PCB
NOTE See 9 6 21 ~or notaoon
Addltlonal exam~les of notatlon:
1~0 O~ ~ OJOrrK1111 ~cr~ 110 O~l
1~0 O ~ ~ r ~ror In rri~cri~o~ o~ 110 O, sri~- 9 6 2 31 i A.1 Error-tree operation A.1.1 Exchange ot l-blocks (see 9.6.2.2.3. Ruie 1, Rule 2.1 )
Scenano 1:
IFD ICC
ù ,00 ù Ii1 0:
A.1.2 Request tor waiting time extension (see 5 6.2 2 3 itel~ Scenarlc 2 A.1.3 IFS adjustment (see 5.6.2.2.3. Rule 4 A.1.3.1 ICC is initiator
Scenano 3:
3 ~ I,n ~, 3 3 S~IFS ~sO~s A.1.3.2 IFD is initiator
Scenano 4:
4 1 1~0 O~
4 3 SIIFS ~ri~sll
S~IF 1~0 O~ 1~0 01 5(1F5 r~ons 111 o~ Ann~ (inform Scen.
~x A atlve3 ~rios
A.1.4 Chaining tunction (see 9.6.2.2.3. Ruie 2.2. Rule 5 A.1.4.1 IFD sends chained l-blocks
Scenario 5:
IFD ICC
1l 1 1) l~ool l l1 o l A.1.4.2 ICC sends chained l-blocks
Scenario 6:
6 l I~oO, 62 ù '^' 63 Ri~, 6 ~ o 6 s 1~1 o~ ~ ~!C Oi
A.1.4.3 ICC uses the M-bit to torce an acknowledgement tor a sent l-block (see NOTE at the ena ot 9.6.2.2.2)
Scenano 7 0 0 . 3 Rll!
~5 1~1 O!
--
...
A.2 Error handlin~ A.2.1 Exchange ot l-blocks
Scenano 8 (Stanlng protocol):
(see 9.6.2.3.2, Rule 7.5) IFD ICC
B 2 ù R~O 9 3 !~O Ol 94 ~- 1~00
Scenario 9 (see 9.6.2.3.2. Rule 7.1. Rule 7.6): 9 1 1(001 9 3 R~o ~ 9~
0~ 1~1 n,
90 01 ~iO 01 Scenano 10: (see 9.6.2.3.2. Rule 7.1, Rule 7.5, Rule 7.6)
10 3 R~OI
R~C, 10 5 1~O Ol
~O 6 ù 1~0 Ol ~n7 1,l n,
Scenano 11: (see 9.6.2.3.2, Rule 7.1, Rule 7.6) 11 1 1~00 1 R~n, 1l 5 R~O l1 7 l~1 l~o ol R~11 l~o ol Scenario 12: (see 9.6.2.3.2, Rule 7.1, Rule 7.2, Rule 7.6)
12 1 I~O 01
122
12 3 R~O
124
12 5 R~OI
Ri1 ~
12 6 ~ 1~0 Ol 127 1~1 O~
Scenario 13: (see 9.6.2.3.2, Ruie 7.i, Ruie 7.2. Rule 7.6
IFD ICC
132
13 3 R101
134
13 5 R~O
l~o o~ R~l, 13 7 R101 1l R -- 1~0 O, 13 ~ I~l 01 A.2.2 Request tor waiting time extension (see 9.6.2.3.2. Rule 7.3)
Scenario 14:
.. ù ,,00, 142 14 3 a~o~
14 5 S(WT~ sDons~
n, Scenario 1 5:
5 1 1(0 01
1S2
15 3 R101 154 ~ SI~VTX R~ou~s 15 5 s(wrx ~-~ons 156 ~ llOO
A.2.3 Request for IFSI iadjustment (see 9.6.2.3.2, Rule 7.3)
Scenarlo 16:
16 1 llO 01
16 3 R~OI
SilFS ~SII
164 ~ S(IFS R4~-s 16 5 Sl(FS ~ oon166 ~ I(OO
Scenarlo 1 7:
IFD ICC ~' 3 R~0
174
17 5 S(IFS ~hsDonse~
176 1'' 1~ n, SCenarIO 18 .e . I~O O
ùe2 ù s ;s ~ 8~ ,e~ .
Scenarlo 19: isee 9 6.2.3.2. Rule, 3) Ons~ ~ Scenarlo 2Q: (see 9.6.2.3.2, Rule 7.3)
20 ~ 1~00, 2 3 S~IFS ~nDon 2 R ~ o, 20 7 R 101
~n o ,,. n.
ù Rl1,
1~0 O~
A.2.4 Chaining ~un~tion (see 9.6.2.3.2, Rule 7.1) A.2.4.1 IFD sends chained l-blocks
Scenario 21:
IFn ICC 2~ 1 ~1011
212
21 3 R(o
214
215 1(111
216
21 7 I(O 01
21 e
,, o ,,. o~
Scenario 22:
222
22 3 Rl 0
22 5 22 e
22 9 111 01
R~Oi ~O O A.2.4.2 ICC sends chained l-blocks
Scenano 23:
23 1 llOOI 232
233 R111
as R~11 236
23 7 1~1
23 e
Scenario 24:
24 1 I~o 01
244
24 5 R11
246
24 7 1 ~1 01
24 e i~lo, 1~0 C RRI 1(1 01 i 1~0 1 1 R~1 1 '~1 01 1~0 O)
A.2.4.3 Sender ot chains initiates abortion of chains (see 9.6.2.3.2. Rule 9,
Scenano 25:
IFD ICC
2s1 2s2
2s 3 S~Ar~ORT ~s~l ~ 2s ~ ù 5~i30R~ ~SDOn#
2ss l~1
2s 6 ~ l~O Ol
2s 7 l~o o)
Scenano 26:
26 l l~o ol 262
26 3 R~ 26- - 5~30R
26e A.2.4.4 Receiver of chains inrtiates abortion of chains
Scenano 27:
271
2~2 4 R11
273 l ~
27 4 ~ S(A~30RT 27 S 5(At30R~ nsD 27 6 ù- R~O
Scenario 28:
2~ 1 2~3 R~1
2~.
1(0 1 1 (1 1l
2~ 6 ~ ORT ~-1
2e7 l~1ol
A.2.5 Resynchroni~ation Scenario 29: ~see 9.6.2.3.2. Ruie 6.2~ IFD ICC
293 ù SIRES~ sDDnsr
294 I(OOI 2A~ 5 .~ l ~ O C Scenario 30: (see 9.6.2.3.2, Rule 6.2, Rule 7.3) ~n~ DW' S(RFSYNCt1 ~--S_D~
30 5 ~ S~RESYNC~1 ~-s~ons~,
306 ~(oO)
307 .~ ,nn
Scenario 31: (see 9.6.2.3.2. Rule 6.2. Rule 7.1 RL~le 7
312 S~RESYNCt1 ~ Sll ~ 31 3 ù R~N~RI,
S~RFSYNC~ r~n
31 6 1(00 31 7 - I(OO
Scenarlo 32:
32 2 S(RESYNCt1 ~ sl, ~ ~
~n~ Dloa~
R~.RI:
32 5 - S(RESYNCh ~on~ 32 6 I~O 01 32 7 ù ~O 01
Scenario 33 (at the start of the protocol):
(see 9.6.2.3.2, Rule 7.1, Rule 7.4.1)
331 I(O.OI ~ lnD n~ons-) 33 2 ~OWT a~ 33 3 R~o) ù ~n~ n~o~ 33 4 ~OWT ~ul~ 33 5 R~O ~ por
336
33 7 ~R_n~ng o~ 7 a~ on
A( m ICC~
5cenano 34 (dunng the orotocoij.
(see 9 6.2.3.2. Rule 7.1, Rule 7 4.2. Rule 7.4.3)
IFD ICC 34 3 R~O~ ~ ~n~ ~-sDon 34 ~ (ewT ~ImeouD 34 5 R(O~ ~ Ino r~s~ons~ 34 6 ù S~RFSYNCr1 ~-soonr~)
3~ 9 ~O 0
34 10 ~ ~(00
Scenano 35 (durins the orotocoi): ~see 9 6 2.3.2. Rule 7.1, Ruie 7.4.2, Ruie, 4.3, Rule 6.4)
IFD ICC 351 1~00~ ù ,no rosDOnsn 352 18W~ ~ml OIJ~; 35 3 ,R.~OI ~ Ino r~Don~ 35 4 i2V~T ~mr,o,J~: 35 5 R~o) ù Ino rr~onsn 35 6 ~3WT ~Imrou~,
35 7 S~RFSYNCh r~r~
35 6 19W~ nm~v4u~ 359 S~RESYNCh ~--S 3510 ~BWT nm~g 35 12 ~ 3WT nm~
3513 IR~non~n~ y O~ c~v o( ~r ~
UDC 351 .755.62: 621 .3.049.77 D~criptort: data processin~ identity cards inte~rated circuit cards. data transmission communication procedure Price based on 13 pages
STANDARD 7816-3
Reproduced B~ GLOeAL ENGII'~EERING DOCUIUENTS ~-- With The Pennission Ot ISO -- Under Ro~-lt~ A~r~ement First edition 1 989-09- 1 5 AMENDMENT 2 1994-12-01
Identification cards--Integrated circuit(s) cards with contacts--
Part 3: Electronic signals and transmission protocols AMENDMENT 2: Revision of protocol type selection Cartes d'identification--Cartes a circuit(s~ integre(s) a contacts-- Partie 3: Signaux electroniques et protocoles de transmission AMENDEMENT 2: Pevision de la selection du type de protocole Reference number ISO/IEC 7816-3:1989/Amd.2:1994~E)
Contents Page
Foreword . ........... . . lii Introduclion .. ... iv 4.2.5 Revislon of CLK . . . 2 5 Revision of operating procedure for integralea circuil(s) cards 2
5.3 Revision of information exchanae .... ... ...
6.1 Hevlslon ot Answer-to-Heset ln synchronous transmlsslon . 3
6.1.1 Revision of bit duration . ...
6.1.4 ~evlsion of struclure and conlenl . . . 3 6.1.4.3 Revision of prolocol Iype T . . . 4
6.1.4.4 Revision of specificalions of the global inlerface byles . ... 5 6.1.4.5 DifferenIiallon between
the negotiable moae and Ihe specific mode . . 6
7 Revision of protocol IvPe selectlon ~PTS) .
8 Modltlcatlons In clause c" . . . . 8 9 Modifications in clause 9 ... ... .. 8
lSO/lEC 1 994
All rights reserved. No parl of this publicaeon may be reproduced or utillzed in any form or by any means, elecIronlc or mechanical, including photocopylng and microfilm, without permission in writinq from the Publisher lSO/IEC Copyrlght Offlce ù P 0 Box 56 ù CH-1211 Geneva 20 ù Switzerland
Printed in Switzerland
Foreword
ISO (the International Organizalion for Slandardizalion) and IEC (the Internal~onal Eleclrotechnical Commission) together form a system for worldwide stanaardization as a whole. National bodies that are members of ISO or IEC particiPate in the deveiopment of Internatlonal Standards through echnical commltlees eslablished by Ihe resPective organization to deal with particular fields of technical aclivily ISO and IEC lechnical committees collaborate in fields of mutual interesl Other international organizations, governmental and non-governmenlal in liaison with ISO and IEC, also take Part in Ihe work
Ihe field of informalion lechnology iSO and IEC have eslablished a join lecnnical commiltee ISO/IEC JTC1 Draft Inlernational Standards adopted by Ihe loinl lechnicai commillee are circulaled tø nalional bodies for voting
Publlcalion as an Inlernalional Slanaard requires al least 75 % approval by the naaonal bodies castlng a vote
Amendment 2 to International Standard ISOIIEC 7816-3: 1989 was prepared by Joint Technical Commiltee ISO/IEC JTC1, Information Technology.
ISO/IEC 7816 consists of the foilowing parts under Ihe general title Identlflcatlon card~s)--Inteqrated clrcult~s) cards wlth contacts:
--Part 1 Physlcal charactenstics --Part 2 Dlmenslons and locatlon of the contacts --Part ~ Electronlc slgnals and transmlsslon protocols --Part 4 Inter-lndustry commands for Interchange
--Part 5 Numbenng system and reglstratlon procedure for applicatlon Identlflers
Introduction
Parl 3 of ISO/IEC 7816 is one of a serles parameters for inlegraled Circuil(s) ca~as cards for international interchange
standards describing ùne conlacls and Ihe use of such
This amendmenl improves the protocol ~ype selecl on he improvement of the protocol type selection induces severa' c arificatlons in other clauses.
These cards are identification cards Intended tOr ,nformation exchange negotiated between tne outsloe and the Integrated circuit in the card As a result of an information exchanse tne card delivers information (computalion resulls, stored data) andlor modifies ils conlent (data storage, even memorizalion)
Identification cards contacts
Integrated circuit(s) cards with Part 3: Electronic signals and transmission protocols AMENDMENT 2: Revision of protocol type selection
ISO/IEC 781 6-3 :1989/Ama.2 : 1 994 (E~
Replace subclause 4 2.5 .
4.2.5 CLK
The actual value of the frequency, delivered by the interface device on CLK, is designatea ~y f For Ihe range of values, see 6.1.4.4.
Duty cycle for asynchronous operation shall be t~etween 45 YO and 55 % of the perioa during sta~le operatlon
When switching the frequency from one value to another, care shall be taken to ensure that no oulse is shorter than 45 % of the shorter period. Two different times are recommended for switchinq the freauencv value:
--either immediateiy after the answer tO reset
--or immediately after a successfui PTS procedure is completed .
No data transmission shall be performed when switching the frequency value
~l~iUllt~;
~epiace the rlrst exlsting paragraphs in ciause 5:
Operating procedure for integrated circuit~s) ards
rhis operating procedure applies to every integrated : rcuit(s) card with contacts.
rhe dialogue between the interface aevice and the card ;hall De conducted through the consecutive operations:
--1--connection and activation of the contacts by the interface device;
--2--reset of the card;
--3--information exchange between the card and
ùhe interface device, always initiated by an Answer-to ;~eset sent by the card;
--4--deactivation of the contacts by the interface ~ev~ce.
Those operations are specified in the following clauses.
NOTE S
Operatlons 2 and ~ may be repeated.
2 An actlve state on VPP should onlv be provided and malntalned when reauested bv the card.
Replace figure 7 .
IR = Internal reset Al = Actlve iow reset SH = Synchronous active hlgh reset GND VCC VPP RST CLK l l o
t i~
200 400 40 000 f < tl C f
~n nnn Figure 1--Reset of the card Nr~TF--The hatched area Indlcates a penod when the state of 1/0 is undefined.
7Q ~ . lOQO/A ~ i . v ù v-_ . ù ~u~ ~ U.~ . I ;7J
Replace figure 4 .
The Initial Character The Format Character . codes Yl and K
The Interface Characters
. global, codes Fl and Dl
global, codes ll and Pl1 giobal coaes N codes Y ana specific codes mode fean~re.s global codes P!2 specific codes Y~ and T TA TB TC are sDecific TD codes Yl~l and T The Historical Characters (max ' 5 charactersl The Check Character Figure 4--Genersl configuration of the Amwer-to-Reset
~la-Jl Ic~
Replace subclause c 1.4 8 .
6.1.4.3 Protocol type T
The four least significant bits of any interface byte TDj indicate a protocol type T, specifying rules to be used to process transmission protocols. When TD1 is not transmitted, T=O is used.
--T = O is the asynchronous half duplex character transmission protocol specified in ciause 8.
--T = 1 is the asynchronous half duplex block transmission protocol specified in clause 9.
--T = 2 and T = 3 are reserved for future full duplex operatlons.
--T = 4 is reserved for an enhanced asynchronous half duplex character transmission protocol
--T = 5 to T = 13 are reserved for future use.
--T= 14 is reserved for protocols not standardized by 1~0
--T = 1 r; ic rPcPrvPrl fnr fln~lrP RxtPn.sion
rA1 TB1 TC 1 and TB2 are the global interface bytes specified in 6.1.4.4. Those global interface bytes shall be interpreted in order to process any transmission protocol correctly .
TA2 provides information on the specific mode of operation of the card as described in 6.1.4 5.
The other interface bytes TA, TBj TCj are the specific interface bytes. Their interpretation depends on the
protocol type indicated by T in TDj_1 .
If more than three interface bytes TAj TBj TCj are defined for a specific protocol type and to be sent in the Answer-to-Reset sequence, shall be sent subsequently by using TD-bytes ~ch all indicate the same orotocol tvDe.
more than one protocol type is indicated and T=O is one of them T=O shall be indicated first.
if only T=O is indicated, TCK shall not be sent In all other cases. TCK shall be sent.
When present, TD1 shall indicate the first offered transmission orotocol
Replace subclause 5 ?
5.3 Information exchange
The card answers after reset with a sequence befined in clause 6.
All information exchanged over the l/O circuit correspond to the execution of commanbs, including a possible PTS procedure as specified in clause 7
The operating procedure of commanas depends on the type of transmission (asynchronous or synchronous) and on the protocol type. The asynchronous haif duplex character transmission protocol, with the interface device as the master, is specified in clause 8. The asynchronous half duplex block transmission protocol is specified in clause 9 ~ISO/IEC 7816-3: 1989/Ama 1 1992)
NOTES
Funher protocol tvpes between the cara and tne Interface device are for funher study
2 The inter-lndustry commanas fo~ Interchange are to be specified In the next pan of ISO/IEC 7816 Other commands are specified either in exlstlng stanaards or In addltlonal stanaards to be defined
Insert the followlng new paragraphs In clause 6 1 6.1 Answer-to-Reset in asynchronous transmission
After the answer to reset, ùhe card following two mobes of operation
--the negotiable mode,
--the specific mode.
In one of the
Those two moaes ot operation are defined in 61 4.5. The indication of the mode is provided In the Answer-to-Reset
ReD~ace su~CIause 6 1 1 6.1.1 Bit duration
The nominal bit duration used on l/O is defined as one ElemenTary Time vnit (etu).
For cards having internal clock ù~e Im~ial etu is 9 600 s.
For cards using the external clock, there is a linear relationship between the Elementary Time Unit used on l/O anb the period provided by the interface device on CLK.
The initial etu is f s where f is in hertz.
See also 6.1 4.1
order to read the initial character (TS), all cards shall ir,itially be operated at least during the answer to reset with f in the range of 1 MHz to 5 MHz.
Any card operated with f in the range of 1 Mhz to 5 MHz shzil answer to reset.
Rep~ace the exlstlng paragraphsIn subc~ause 6 1.4 6 .1. 4 Structure and content
A reset oPeration results in an answer from the card consisting of the initial character TS, followed by at most 32 characters in the following order
--T0 . ........Format character ........Mandatory
--TAj TB, TCj TDj ... !nterface characters .... Optional
--T1 T2..TK ...Histoncal characters .....Optional --TCK .........Check character .......Conditional
See 6 1 4 1 to 6.1 4.5 and figure 4
~OT~--The use of TA2 is condlaoned bv the mode of operatlon (see 6.1.4.5).
In subclause 6.1.4 4, replace the firs t two paragraphs and the paragraphs under 'Parameters ...', 'Programmmg voltage ... ' and 'Extra guardtlme ... ', the paragraphs under 'Integer values ' and 'Correspondence . ' remaln unchanged. Replace tables 6 7 and 8.
6.1.4.4 Specifications of the global interface bytes
Among the interface bytes possibly transmitted by the card in the Answer-to-Reset, this subclause defines only the global interface bytes TA1 TB1 TC 1 TB2.
I hose global interface bytes convey information to determine parameters that the interface device shall take into account
Parameters F, D, I, P, N
In the negotiable mode, as specified in 6.1.4.5, the initial etu specified by the formulae given in 6.1.1 and repeated below remains valid until a PTS procedure has been successfully completed. The initial etu is replaced by the work etu immeaiately after a successful execution of the PTS procedure (explicit protocol type selection)
In the specific moae, as specified in 6.1 4 5, the initial etu IS replaced by the work etu immediately after the answer to reset.
F is the clock rate conversion factor and D is the bit rate adjustment factor to determine the work etu.
For internal clock caras Initial etu = 9 600 s For external clock cards
372 Initial etu = f s where f is in hertz.
Work etu = r~ x q finn Work etu = D x f s
The minimum value of f shall be 1 MHz. The maximum value of f is given by table 6.
I and P define the active state at VPP. --Maximum programming current: Ipp = I mA. --Programming voltage: Vpp = P V.
N, when in the range from 0 to 254, is an extra guardtime requested by the card. Before receiving the next character, the card requires a delay of at least ~12+N) etu from the start leading edge of the previous character. No extra guardtime is used to send characters from the card to the interface device. N=255 has a special meaning defined at the end of this subclause.
The default values of these parameters are
F=372; D=1; I=50; P=5; N=0.
These parameters are described in greater detail at the end of this subclause under Integer Values to Parameters Correspondence.
Table 6--Clock rate conversion factor F
Fl 0000 0001 0010 0011 | 0100 0101 0110 0111 l F Internal Clock 372 558 744 | 1116 1488 1860 RFU f (max) M Hz - 5 6 8 | 12 16 20 l
RFU = Reserved for Future Use
Fl 1000 ~001 1010 1011 1100 1101 1110 1111 F RFU 512 768 1024 1536 2048 RFU RFU f (max) M Hz - 5 7,5 10 15 20
Table 7--Bit rate adjustment factor D
Dl | 0000 | 0001 | 0010 | 0011 | 0100 | 0101 | 0110 | 0111 D | RFU | 1 | 2 | 4 | 8 | 16 | 32 | RFU Dl 1000 1001 1010 1011 1100 1101 1110 1111 D 12 20 1~ 1/4 1/8 1/16 1/32 1/64
IS O/IEC 7816-3:1989/A m d.2:1994IE) Programming voltage factor P
Pl1 from 5 to 25 gives the value of P in voits. Pl1=0 indicates that VPP is not connected in the card whicn generates an internal programming voltage from VCC. other values of Pl1 are reserved for future use.
When Pl2 is present, the indication of Pl1 snouid be ignored. Pl2 from 50 to 250 gives the value of P in 0,1 V Other values of Pl2 are reserved for future use.
Table 8--Maximum programming current factor I 11 | 00 | 01 I, 1 25 1 50 1 100 1 ~~
Extra guardtime N
N codes directly the extra guardtime, from 0 to 254 etu. N=255 indicates that the minimum delay between the start leading edges of two consecutive cnaracters is the same in both directions of transmission The value of this minimum delay is
--12 etu for the T=0 asynchronous half-duplex character transmission protocol,
--11 etu for the T=1 asynchronous half-auplex block transmission protocol
Insert the new followlnq subclause ana two flqures
6.1.4.5 Differentiation between the negotiable mode and the specific mode
In the nogotiable mode of operation, the default values of parameters F and D (see 6.1.4.4) used during the answer to reset and the first offered protocol type given in the answer to reset shall apply until a successful PTS procedure is performed. The negotiable moae may be changed directly to the specific mode by use o~ the PTS functlon .
NOTE--A reset issuea In the negoaable mode maV swltch ~he card Into the specific mode.
In the specific mode of operation, the Darameters F and D (see 6.1.4.4) and the protocol type required in the answer to reset shall apply directly after the answer to reset. A reset may be initiated by the interface device to invoke the neaotiable mode in the card.
Selection and switching of modes of operation are shown in figure X.
~u~sequenl resel ATR: Speclfic moae ATR: Negotlable mode Subsequent reset SPecific mode PTS Neaotiable mode Figure X--Schematic representation of mode selection and switching Implicit protocol type selection in negotiable mode
ne first indicated protocol is appiicable mmediately after the answer to reset as long as the first character sent by the interface device to the card allows an unambiguous distinction between a PTS request and a command of the protocol
Consequently, cards supporting only one protocol and only the default values of the transmission parameters need not support the PTS procedure
NOTE--If T=0 IS presenmn a multi-protocol card, then T=0 shall be Indlcated first In the Answer-to-Reset Therefore, in negotlable mode, onlv T=0 can be Impllcltly selected in this card
Coding of TA2, the specific mode byte in specific m o d e
When present, TA2 indicates the specific mode of operation of the card and descnDes the relevant features. The negotiable mode of the card is denoted by the absence of TA2.
The coding of TA2 is according to figure Y
b8 I b7 I b6 I b51 b4 I b3 I b2 I bl
b8 ....Indicator of ability for changlng the mode of operation Capable to change when b8=0 Unable to change when b8=1
b7-b6 . RFU (00 when not used)
b5 ...Indicator of definition of parameters Defined by the Interface bytes when bS=0 Implicitly defined. not bv the Interface bytes when bS=1 T.....Protocol type to be used In the specific mode
Figure Y--Coding of the specific mode byte
NOTES
When a card transmltang TA2 ,s mtroduced In an interface device not aware of the exlstence of the specific mode, then the card cannot rely on an additional reset belng provided by the interface device to switch to the negotiable mode.
2 When an interface devlce has detected a TA2 byte, then the Interface device should not Issue a second reset before the answer to reset IS completely received or the card has timed out .
Replace clause 7.
7 Protocol type selection (PTS)
This ciause specifies an explicit protocol type selection, including parameter selection. This clause applies only immediately after the answer to reset and only when the card is in the negotiable mode as defined in 6.1.4.5
7.1 Scope
The implicit selection of a protocol in the negotiable mode is performed by using the first indicated Drotocol after the answer to reset. The implicit selection of parameters in the negotiable mode is performed by continuing to use the default values of F and D after the answer to reset
In order to use a protocol type and/or values of parameters different from that offered by the impliclt selection, the interface device shall initiate an explicit selection of the protocol type and/or the values of F and D according to the following specificatlons
7.2 Conditional usage
If only one protocol type and only the aefault values of F and G are indicated in the Answer-to-Reset, this transmission protocol with F=372 ana D=1 shall start immediately after the transmission of the Answer-toRe.set
If the card is able to process more than one protocol type and if one of those protocol types is indicated as T=0, then the protocol type T=0 shall be indicated in TD1 as the first offered protocol. If no PTS is performed, then the first offered protocol shall be used immediately after the answer to reset (implicit protocol type selection).
An interface device which does not support PTS and the implicitly selected protocol and parameters proposed by the card may either reset the card to try to switch from the negotiable mode to a specific moae supported Dy the interface device or reject the card.
NOTE--If either T=0 o- T=1 is offered wllh non-default values of F and/or D, then the Interface devlce may
ù either select Impllcltly the protocol wlth the default values of F and D,
ù or Initiate a PTS procedure under default values to negotiate the use of non-default values
7.3 PTS protocol
Only the interface device is permitted to start the PTS procedure.
--The interface device sends a PTS request to the card.
--If the card receives an erroneous PTS request, it will not send any response.
-- If the card receives a correct PTS request, it answers by sending a PTS response, if implemented, or the initial waiting time will be exceeded.
--If the initial waiting time is exceeded, the interface oevice shall either reset or reject the card.
--If the interface device receives an erroneous PTS response, it shall either reset or reject the card.
--If the PTS exchange is unsuccessful, then the interface device shall either reset or reject the card.
The parameters for the transmission of the PTS request and PTS response shall correspond to those used during the transmission of the Answer-to-Reset regarding the values of F and D, the bit rate and the convention detected by TS.
After a successful PTS exchange, the selected protocol type and/or the selected transmission parameters F and D shall be used.
7.4 Structure and content of PTS requ~nt snd PTS response
The PTS request and PTS response each consist of one initial character PTSS, followed by a format character PTS0, three optional parameter characters PTS1, PTS2, PTS3 and a character check PCK as the last byte.
The Initial Charscter The Forrnat Character Parameter Charscten Thc ChQclr CharactQr Figure Z--Structure of PTS request / re~pon~
PTSS identifies the PTS request or PTS response and is coded ' F F '
PTS0 indicates by the bits b5, b6, b7 set to 1 the presence of the subsequently sent optional characters PTS1, PTS2, PTS3, respectively. It codes over the least significant bits b4 to bl the selected protocol type T as coded in TDbytes. The most significant bit b8 (default: b8=0) is reserved for future use.
PTS1 codes Fl and Dl in the same way as TA1. The corresponding values of F and D should lie in the range between the default values and the values indicated by TA1 The interface device may send PTS1 in order to indicate the selected F and/or D values to the card. If PTS1 is not sent F=372 and D=1 are assumed as defaults. The card eithe; acknowledges both the F and D values by
ISO/IEC 7816-3 :1989/Amd,2 : lY~4 ~t)
echoing PTS1 or does not sena PTS1 indicating the use of the default values.
The coding and use of PTS2 and PTS3 are reserved for future use.
The value of PCK shall be such that the exclusive-oring of all characters from PTSS to PCK inclusive is null.
7.5 Definition of a successful PTS exchange
If the PTS response echoes exactly the PTS request, then the PTS exchange is successful. case. Other cases may occur. A PTS exchange is also successTuI wnen response is in the following conditions.
This is the most common --PTSS Response = PTSS_Request, --PTS0_Response PTS
ù bl to b 4 shall be echoed,
ù b5 may be echoed, if b5 = 1 PTS1_Response = PTS1_Request, if b5 = O PTS1_Response IS not present, meanlng that the default vaiues oT F and D shall be used
ù b6 may be echoed, if b6= 1 PTS2_Response= PTS2_Request, if b6 = O PTS2_Response and PTS2_Request are both absent.
ù b7 may be echoed if b7 = 1 PTS3_Response = PTS3_Request, if b7 = O PTS3_Response and PTS3_Request are both absent
Any otner case of PTS exchange shall be Interpreted as unsuccessf ul .
63 IS O/IEC In clause 8, replace rhe second paragraph
This protocol uses the physical parameters according to the mode of operation (see 6.1.4.5).
In clause 8.1, replace 'work etu' by 'current etu Changes to AMENDMENT 1 to ISO/IEC 7816-3 /n clause 9, replace the sentence on llnes 28 to 31
This protocol uses the character frame defined in the answer to reset and the physical parameters defined accordins to the mode of operation lsee 6.1.4.5).
in subclause 9 2, replace the flrst sentence
The character frame is as defined for the answer to reset in 6.1.2 and 6.1.4.4 (last paragraph) and accordinq to the mode of operation in 6.1.4.5.
In subclause 9 5.2.1, delete the sentence 'See 6.1.4 4. definltion of work etu ', replace the two remaln~ng 'work etu' by 'current etu'
In subclause 9 5 2 2, replace f5 by f in the first formula; replace the two 'work etu' bv 'current etu
In subclause 9 5 2 3. replace 'work etu' by 'current etu'.
ICS 35.240.40
Dexriptors: data processing, data storage devices, identification cards, ic cards. data transmission. communication procedure, protocols.
Price based on 8 pages
I 1'1 I t~1'1 ~ I I"1'1 '' L ~'J/~t~,
STANDARD 7816-4
Reproduced By GLOBAL ENGI~EERING DOCUMENTS With The Pemlission Of IS0 Under Ro~alty Agre~ment
First edition 1 995-09-01
Information technology Identification cards contacts
Integrated circuit(s) cards with Part 4: Interindustry commands for interchange
Technologies de l'information--Cartes d'identification--Cartes a circuit(s) integre(s) a contacts--
Partie 4: Commandes intersectorielles pour les echanges Reference number ISO/IEC 78164:1995(E)
ISO/IEC 781~4:1Y95 (E)
Contents Page Foreword ....... ........... ................... ..... iii Introduction .... ... .. ....... ..... iv 1 Scope .............................................1 2 Normative references ...................................... 3 Definitions .............................. 2 4 Abbreviations and notation ......................................3 5 Basic organizations ...................... 3 5.1 Data structures ......................... 3 5.2 Security architecture of the card ....... 6 5.3 APDU message structure .................. 7 5.4 Coding conventlons for command headers, data fields and response trailers ....... 9 5.5 Logical channels ........................ 12 5.6 Secure messaging ........................ 12 6 Basic interindustry commands .............16 6.1 READ BINARY command ..................... 16 6.2 WRITE alNARY command .................... 17 6.3 UPDATE 81NARY command ................... 17 6.4 ERASE BINARY command .................... 18 6.5 READ RECORD(S) command .................. 19 6.6 WRITE RECORD command .................... 20 6.7 APPEND RECORD command ................... 21 6.8 UPDATE RECORD command ................... 22 6.9 GET DATA command ..:..................... 23 6.10 PUT DATA command ........................ 24 6.11 SELECT FILE command ..................... 25 6.12 VERIFY command .......................... 26 6.13 INTERNAL AUTHENTICATE command ........... 27 6.14 EXTERNAL AUTHENTICATE command ........... 27 6.15 GET CHALLENGE command ................... 28 6.16 MANAGE CHANNEL command .................. 29 7 Transmission-oriented interindustry commands ..29 7.1 GET RESPONSE command ......................30 7.2 ENVELOPE command ..........................30 8 Historical bytes ..............................31 9 ADDlication-indeDendent card services .........3 3
Annexes
A Transportation of APDU messages by T=O ........35 B Transportation of APDU messages by T=1 ........39 C Record pointer management ...................................................41 D Use of the basic encoding rules of ASN.1 ......42 E Examples of card profiles .....................43 F Use of secure messaqinq .......................45
~ISO/IEC 1995
All rights reserved. Unless otherwise specified. no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permlssion in writing from the publisher.
ISO/IEC Copyright Office ù Case Postale 56 ù CH-1211 Geneve 20 ù Switzerland Printed in Switzerland
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non~overnmental, in liaison with ISO and IEC. also take Dart in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 7816-4 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology.
ISO/IEC 7816 consists of the following parts, under the general title Information technology--Identification cards--Integrated circuit(s) cards with contacts.
--Part 1: Physical characteristics.
--Pan 2. Dimensions and location of the contacts.
--Part 3. Electronic signals and transmission protocols.
--Part 4 . Interindustry commands for interchange,
--Part 5. Numbering system and registration procedure for application identifiers.
--Part 6: Intenndustry data elements.
Annexes A and B form an integral part of this part of ISO/IEC 7816. Annexes C, D, E and F are for information only.
ISO!IEc 781~4: 1995 !F! ~ ISO!IEC
Introduction
This part of ISO/IEC 7816 is one of a series of standards describing the parameters for integrated circuit(s) cards wlth contacts and the use of such cards for international interchange.
These cards are identification cards intended for information exchange negotiated between the outside and the integrated circuit in the card. As a result of an information exchange, the card delivers information (computation results, stored data), and/or modifies its content (data storage, event memorization)
Identification cards Information technology Integrated circuit(s) cards with contacts -- Part 4: Interindustry commands for interchange
1 Scope
This part of ISO/IEC 7816 specifies
--the content of the messages, commands and responses, transmitted by the interface device to the card and conversely,
--the structure and content of the historical bytes sent by the card during the answer to reset,
--the structure of files and data, as seen at the interface when processing interindustry commands for interchange,
--access methods to files and data in the card,
--a security architecture defining access rights to files and data in the card,
--methods for secure messaging,
--access methods to the algorithms processed by the card. It does not describe these algorithms.
It does not cover the internal implementation within the card and/or the outside world.
It allows further standardization of additional interindustry commands and security architectures.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this part of ISO/IEC 7816. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this part of ISO/IEC 7816 are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Members of IEC and ISO maintain reaisters of currentlv valid International Standards
ISO 31 66 :1 993, Codes for the representation of names of countnes.
ISO/IEC 7812-1
1993, Idennfication card~ u ~ -u~r~---rart 1: Numbering system
ISO/IEC 781 6-3 :1 989, Identification cards--Integrated circuit(s) cards with contacts--Part 3. Electronic signals and transmission protocols.
Amendment 1 :1992 to ISO/IEC 7816-3: 1989, Protocol type T=1, asynchronous half duplex block transmission protocol.
ISO/IEC 781~4:1995 (E)
Amendment 2: 1 994 to ISO/I EC 781 6-3: 1 989, Revision of Protocol tvpe selection.
ISO/IEC 7816-5:1994, Identification cards--Integrated circvit(s) cards with contacts--Part5: Numbering system and registrahon procedure for application identifiers.
ISO/IEC 7816-6:--1), Identification cards -- Integrated circuit(s) cards with contacts--Part 6 . Interindustry data R/~mf~n ts
ISO/I EC 8825 :1 990 2 ) , Informa tion technology --Open Systems Interconnection--Specification of aasic Encoding Flules for Abstract Syntax Notation One (ASN. 1).
ISO/IEC 9796: 1991, Information technology--Security techniques--Digital signature scheme giving message recovery.
ISO/IEC 9797: 1994, Information technology--Security techniques--Data Integrity mechanism using a cryptographic check function employing a block cipher algonthm.
ISO/IEC 9979: 1991, Data cryptographic techniques -- Procedures for the registration of cryptographic algorithms.
ISO/IEC 10116:1991, Infomnation technology--Modes of oaeration for an nbit block cioher aloonthm.
ISO/IEC 10118-1: 1994, Information technology -- Securitv techniaues--Hash-functions--Part 1. General.
ISO/IEC 10118-2: 1994, Information technology -- Security techniques--Hash-functions--Part 2. Hashfunctions usinq an n-bit block cipher al40nthm.
3 Definitions
For the purposes of this part of ISO/IEC 7816, the following definitions apply.
3.1 Answer-to-Reset file: Elementary file which indicates oDeratina characteristics of the card.
3.2 command-response pair: Set of two messages: a command followed by a response.
3.3 data unit: The smallest set of bits which can be unambiguously referenced.
3.4 data element: Item of information seen at the interface for which are defined a name, a description of logical content, a format and a coding.
3.5 data object: Information seen at the interface which consists of a taq, a lenath and a value (i.e.. a data
1 ) To be published. 2) Currentl,v under revision.
~ISO/IEC
element). In this part of ISO/IEC 7816, data objects are referred to as BER-TLV, COMPACT-TLV and SIMPLE-TLV data objects .
3.6 dedicatedfile: File containing file control information and, optionally, memory available for allocation. It may be the parent of EFs and/or DFs.
3.7 DF name: String of bytes which uniquely identifies a dedicated file in the card.
3.8 directory file: Elementary file defined in part 5 of ISO/IEC 7816.
3.9 elementary file: Set of data units or records which share the same file identifier. It cannot be the parent of another file.
3.10 file control parameters: Logical, structural and security attributes of a file
3,11 file identifier: A 2-bytes binary value used to address a file.
3.12 file management data: Any information about a file except the file control parameters (e.g., expiratlon date. aDDIication label).
3.13 internal elementary file: Elementary file for storing data Interpreted by the card
3.14 masterfile: The mandatory unique dedicated file representing the root of the file structure.
3.15 message: String of bytes transmitted by the interface device to the card or vice-versa, excluding transmission-oriented characters as defined in part 3 of ISO/IEC 7816.
3.16 parent file: The dedicated file immediately preceding a glven file within the hierarchv.
3.17 password: Data which may be required by the application to be presented to the card by its user.
3.18 path: Concatenation of file identifiers without delimitation. If the path starts with the identifier of the master file, It is an absolute path.
3.19 provider: Authority who has or who obtained the riqht to create a dedicated file in the card.
3.20 record: String of bytes which can be handled as a whole by the card and referenced by a record number or bv a record identifier.
3.21 record identifier: Value associated with a record that can be used to reference that record. Several records may have the same identifier within an elementary file.
3.22 record number: Sequential number assigned to each record which uniquely identifies the record within its elementary file.
3.23 working elementary file: Elementary file for storing data not interpreted by the card.
5.3.3 Response APDU
Illustrated by figure 6 (see also table 7), the response APDU defined in this part of ISO/IEC 7816 consists of
--a conditional body of variable length,
--a mandatory trailer of 2 bytes (SW1 SW2).
Body Trailer IData fieldl I SW1 SW2 Fiqure 6--ResDonse APDU structllre
The number of bytes present in the data field of the response APDU is denoted by Lr.
The trailer codes the status of the receiving entity after processing the command-response pair.
NOTE--If the command is aborted, then the response APDU Is a trailer coding an error condition on 2 status bytes.
5.4 Coding conventions for command headers, data fields and response trailers
Table 6 shows the contents of the command APDU Table 6--Command APDU contents
Code Name Length Description CLA Class 1 Class of Instructlon INS Instruclion 1 Instrucoon code Pl Parameter 1 1 Instruction parameter 1 P2 Parameter 2 1 Instructlon parameter 2 Lc Length vanable Number of bytes present In field 1 or 3 the data field of the command Data Data vanable Stnng of Dvtes sent In the field = Lc data fleld of the command Le Length vanable Maxlmum numDer of bytes field < 3 expected Ir the data field of the response to the command
Table 7 shows the contents of the response APDU.
Table 7--Response APDU contents
Code Name Lengt~ Description Data Data vanable Stnng of bytes recelved In field = Lr the data field of the response SW1 Status byte 1 1 Command processlng status SW2 Status byte 2 1 Command processlng qualifier
The subsequent clauses specify coding conventions for the class byte, the instruction byte, the parameter bytes, the data field bytes and the status bytes.
Unless otherwise specified. in those bytes, RFU bits are coded zero and RFU bytes are coded '00'.
5.4.1 Class byte
According to table 8 used in conjunction with table 9, the class byte CLA of a command is used to indicate
--to what extent the command and the response comply with this part of ISO/IEC 7816,
--and when applicable (see table 9), the format of secure messaging and the logical channel number.
Table 8--Coding and meaning of CLA
Value Meaning
'OX' Structure and coding of command and response according to this part of ISO/IEC 7816 (for codlng of X, see table 9)
10' to 7F' RFU '8X. '3X Structure of command and response accordlng to thls part of ISO/IEC 7816. Except for X (for codlng, see table 9). the codlng and meanlng of command and response are propnetary 'AX' Unless otherwlse speclfied by the appllcatlon context, structure and codlng of command and response accordlng to thls Part of ISO/IEC 7816 (for codlng of X, see table 9) 'B0' to CF' Structure of command and response accordlng to thls part of ISO/IEC 7816 'D0 to FE' Dropnetar~ structure and coding ot command and response FF~ Reserved for PTS
Table 9--Coding and meaning of nibble 'X' when CLA = 'OX', '8X', '9X' or'AX'
b4 b3 b2 b1 Meaning x x - - Secure messaging (SM) format
O x - - ù No SM or SM not according to 5.6 O O - - --No SM or no SM Indlcatlon O 1 - - --Propnetary SM format
x - - ù Secure messaging according to 5.6 0 - - --Command header not authenticated ----Command header authentlcated
(see 5.6.3.1 for command header usage)
--x x Logical channel number (according to 5.51
(b2 bl = 00 ùvhen logical channels are not used or when logical channel # O is selectedl
5.4.2 Instruction byte
The instruction byte INS of a command shall be coded to allow transmission with any of the protocols defined in part 3 of ISO/IEC 7816. Table 10 shows the INS codes that are consequently invalid.
ISO/IEC 781~4:1995 (E) Table 10--Invalid INS codes b8 b7 b6 bS b4 b3 b2 b1 | Meaning x x x x x x x 1 --Odd values O 1 1 O x x x x --'6X' 0 0 1 x x x x --'9X'
Table 11 shows the INS codes defined in this part of ISO/IEC 7816. When the value of CLA lies within the range from '00' to '7F' the other values of INS codes are to be assigned by ISO/IEC JTC 1 SC17.
Table 11--INS codes defined in this part of ISO/IEC 7816
Value Command name Clause 'OE' ERASE elNARY 6 4 '20' VERIFY 6 12 ~70~ MANAGE CHANNEL 6.16 '82' EXTERNAL AUTHENTICATE 6 14 '84' GET CHALLENGE 6 15 88 INTERNAL AUTHENTICATE 6 13 ~A4~ SELECT FILE 6 11 'BO' READ BINARY 6 1 'B2' READ RECORD(SI 6 5 CO' GET RESPONSE 7 1 C2' ENVELOPE 7 2 CA GET DATA 6.9 'DO' WRITE 31NARY 6.2 ~D2~ WRITE RECORD 6.6 D6 UPDATE 31NARY 6 3 'DA' PUT DATA 6.10 DC' UPDATE RECORD 6.8 'E2' APPEND RECORD 6 7
5.4.3 Parameter bytes
The parameter bytes P1-P2 of a command may have any value. If a parameter byte provides no further qualification, then it shall be set to '00'.
5.4.4 Data field bytes
Each data field shall have one of the following three structures. --Each TLv-coded data field shall consist of one or more TLv-coded data objects. --Each non TLv-coded data field shall consist of one or more data elements, according to the specifications of the respective command. --The structure of the proprietary-coded data fields is not specified in ISO/IEC 7816.
n
w iSOiiEC
This part of ISOtlEC 7816 supports the following two types of TLv-coded data objects in the data fields.
--RER-TLv data object.
--SIMPLE-TLV data obiect.
ISO/IEC 7816 uses neither '00' nor 'FF' as taq value.
Each 3ER-TLV data object shall consist of 2 or 3 consecutive fields (see ISO/IEC 8825 and annex D).
--The tag field T consists of one or more consecutive bytes. It encodes a class, a type and a number.
--The length field consists of one or more consecutive bytes. It encodes an integer L
--If L is not null, then the value field V consists of L consecutive bytes. If L is null, then the data object is empty: there is no value field.
Each SIMPLE-TLV data object shall consist of 2 or 3 consecutive fields.
--The tag field T consists of a single byte encoding only a number from 1 to 254 (e.g., a record identifier). It codes no class and no construction-type.
--The length field consists of 1 or 3 consecutive bytes. If the leading byte of the length field is in the range from '00' to 'FE', then the length field consists of a single byte encoding an integer L valued from 0 to 254. If the leading byte is equal to 'FF', then the length field continues on the two subsequent bytes which encode an integer L with a value from 0 to 65 535.
--If L is not null, then the value field V consists of L consecutive bytes. If L is null, then the data object is empty: there is no value field.
The data fields of some commands (e.g., 3ELECT RLE), the value fields of the SIMPLE-TLV data objects and the value fields of the some primitive 3ER-TLV data objects are intended for encoding one or more data elements.
The data fields of some other commands (e.g., record-oriented commands) and the value fields of the other primitive 3ER-TLV data objects are intended for encoding one or more SIMPLE-TLV data objects.
The data fields of some other commands (e.g., object-oriented commands) and the value fields of the constructed SER-TLV data objects are intended for encoding one or more 3ER-TLV data objects.
NOTE--F~efore. between o, after TLV-coded data objects. ~00 o, ~FF~ bytes without any meanlng may occur ~e.g., due to erased or modifled TLV-coded data objects).
5.4.5 Status bytes
The status bytes SW1-SW2 of a response denote the processing state in the card. Figure 7 shows the structural scheme of the values defined in this Dart of ISO/IEC 7816.
SW1 SW2
Process| completed Process Normal Warning Execution Checking processing processlng error error ~61XX~ 62xX 63xx 64xx 65xx '67xX' sooo (see nole~ ~see note) to ~6FXX~
Figure 7--Structural scheme of status bytes
NOTE--When SW1 = '63' or '65', the state of the non-volatile memory is changed. When SW1 = 6X' except '63' and '65', the state of the non-volatile memory is unchanged.
Due to specifications in part 3 of ISO/IEC 7816, this part does not define the following values of SW1-SW2:
--'60XX';
--'67XX', '6BXX', '6DXX', '6EXX', '6FXX', in each case if 'XX' ~ '00';
--'9XXX', if 'XXX' .~ '000'
The following values of SW1-SW2 are defined whichever protocol is used (see examDIes Ir annex A).
--If a command is aborted with a response where SW1 = '6C', then SW2 indicates the value to be given to the short Le field (exact length of requested data) when re-issuing the same command before issuing any other command.
--If a command (which may be of case 2 or 4, see table 4 and figure 4) is processed with a response where SW1 = 61', then SW2 indicates the maxlmum value to be given to the short Le field (length of extra data still available) in a GET RESPONSE command issued before issuinq anv other command.
NOTE--A functlonality similar to that offered by '61XX' may be offered at application level by '9FXX' However, appllcatlons may use '9FXX' for other purposes.
Table 12 completed by tables 13 to 18 shows the general meanings of the values of SW1-SW2 defined in this part of ISO/IEC 7816. For each command, an appropriate clause provides more detailed meaninqs.
Tables 13 to 18 specify values of SW2 when SW1 is valued to '62', '63', '65', '68', '69' and '6A'. The values of SW2 not defined in tables 13 to 18 are RFU, except the values from 'F0' to 'FF' which are not defined in this part of ISO/I EC 7816.
Table 12--Coding of SW1-SW2 . Sw1-Sw2 Meanmg
Normal processings '9000' --No further qualification '61XX' --SW2 indicates the number of response bytes
still available (see text below)
Warning processings '62XX' --State of non-volatile memory unchanged
(further qualification in SW2, see table 13)
'63XX' --State of non-volatile memory changed
(further qualification in SW2, see table 14)
Execution errors '64XX' --State of non-volatile memory unchanged
(SW2 = '00', other values are RFU)
'65XX' --State of non-volatile memory changed
(further qualification in SW2. see table 15)
'66XX' Reserved for secunty-related Issues (not defined in this part of ISO/IEC 7816) Checking errors '6700' --Wrong length '68XX' --Functlons in CLA not supported
(further qualification in SW2, see table 16)
'69XX' --Command not allowed
(further qualificatlon in SW2, see table 17)
'6AXX' --Wrong parameter(s) P1-P2
(further qualification in SW2, see tab)e 18)
'6B00' --Wrong parameter(s) P1-P2 '6CXX' --Wrong length Le: SW2 indicates the exact
length (see text below)
'6D00' --Instrucaon code not supponed or invalid '6 E00 ' --Class not supported 6F00' --No preclse dlagnosls
Table 13--Coding of SW2 when SW1 = '62'
SW2 Meaning
'00' No informatlon glven '81' Part of returned data may be corrupted '82' End of file /record reached before reading Le bytes '83' Selected file invalldated '84' FCI not formatted according to 5.1.5
Table 14--Coding of SW2 when SW1 = '63'
SW2 Meaning
'00' No information glven 81' File filled up by the last write 'CX' Counter provided by 'X' (valued from 0 to 15) (exact meaning depending on the command)
Table 15--Coding of SW2 when SW1 = '65'
SW2 Meaning '00' No information glven '81' Memory failure
ISO/IEC 7816~4:1995 (E) Table 16--Coding of SW2 when SW1 = '68' SW2 Meaning '00' No information given '81' Logical channel not supponed '82' Secure messaging not supported Table 17--Coding of SW2 when SW1 = '69'
SW2 Meaning
.
'00' No information given '81' Command incompatible with file struc '82' Secunty status not saasfied '83' Authentlcation method blocked '84' Referenced data invalidated '85' Conditions of use not satisfied '86' Command not allowed (no current EFi '87' Expected SM data objects missing '88' SM data objects Incorrect Table 18--Coding of SW2 when SW1 = '6A' _
SW2 Meaning
.
'00' No informanon glven '80' Incorrect parameters In the data field '81' Funcaon not supponed '82' File not found '83' Record not found '84' Not enough memory space in the file '85' Lc inconslstent wlth TLV structure '86' Incorrect parameters P1-P2 '87' Lc inconsistent with P1-P2 '88' Referenced data not found
5.5 Logical channels
5.5.1 General concept
A logical channel, as seen at the interface, works as a logical link to a DF
There shall be independence of activity on one logical channel from activity on another one. That is, command interdependencies on one logical channel shall be independent of command interdependencies on another Iogical channel. However, logical channels may share application-dependent security status and therefore may have security-related command interdependencies across logical channels (e.g., password verification).
Commands referring to a certain logical channel carry the respective logical channel number in the CLA byte (see tables 8 and 9). Logical channels are numbered from O to 3. If a card supports the logical channel mechanism, then the maximum number of available logical channels is indicated in the card capabilities (see 8.3.6).
Command-response pairs work as currently described. This part of ISO/IEC 7816 supports only commandresponse pairs which shall be completed before initiating a subsequent command-response pair. There shall be no interleaving of commands and their responses across logical channels; between the receipt of a command and the sending of the response to that command only one logical channel shall be active. When a logical channel is opened, it remains open until explicitly closed by a MANAGE CHANNEL command.
NOTES
More than one logical channel may be opened to the same DF, if not excluded (see file accessibili~ in 51.5).
2 More than one logical channel may select the same EF, if not excluded (see file accessibility in 5.1.5).
3 A SELECT FILE command on anV logical channel will open a current DF and possibly a current EF. Therefore, there is one current DF and possibly one current EF per logical channel as a result of the behavior of the SELECT FILE command and file accessing commands uslng a shon EF identifler.
5.5.2 Basic logical channel
The basic logical channel is permanently available. When numbered, its number is 0. When the class byte is coded according to tables 8 and 9, the bits bl and b2 code the logical channel number.
5.5.3 Opening a logical channel A logical channel is opened by successful completion of
--either the SELECT FILE command referencing a DF by assigning a logical channel number other than O in the class byte;
--or the open functlon of the MANAGE CHANNEL command either asslgning a loglcal channel number other than O in the command APDU or requesting a logical channel number to be assigned by the card and returned in the response.
5.5.4 Closing a logical channel
The close function of the MANAGE CHANNEL command may be used to explicitly close a logical channel using the logical channel number. After closing, the logical channel number will be available for re-use. The basic logical channel shall not be closed.
5.6 Secure messaging
The goal of secure messaging (SM) is to protect IPart of I the messages to and from a card by ensuring two basic security functions: data authentication and data confidentiality.
Secure messaging is achieved by applying one or more security mechanisms. Each security mechanism involves an algorithm, a key, an argument and often, initial data.
ù The transmission and reception of data fields may be interleaved with the execution of security mechanisms. This specification does not preclude the determination by sequential analysis of which mechanisms and which security items shall be used for Drocessinc the remaining part of the data field.
ù Two or more security mechanisms may use the same algorithm with different modes of operation (see ISO/IEC 10116). The present specifications of the padding rules do not preclude such a feature.
This clause defines 3 types of SM-related data objects:
--plain value data objects, intended for carrying plain data,
--security mechanism data objects, intended for carrying computational results of security mechanisms,
--auxiliary security data objects, intended for carrying control references and response descriptors
5.6.1 SM format concept
In each message Involving security mechanisms based on cryptography, the data field shall comply with the basic encoding rules of ASN.1 (see ISO/IEC 8825 and annex D), unless otherwise indicated by the class byte (see 5.4.1).
In the data field, the present SM format may be selected
--implicitly, i e., known before issuing the command,
--explicitly, i.e., fixed by the class byte (see table 9).
The SM format defined in this part of ISO/IEC 7816 is EER-TLV coded.
ù The context-specific class of tags (range from '80' to 'BF') is reserved for SM.
ù Data objects of the other classes may be present (e.g., data oblects of the application-specific class).
ù Some SM-related data objects are recursive: their plain value field is still E~ER-TLV coded and there, the context-specific class is still reserved for SM
In the context-specific class, the bit b1 of the tag fixes whether the SM-related data object shall (b1=1) or not (b1=0) be integrated in the computation of a data object for authentication. If present, the data objects of the other classes shall be inteqrated in such a computation.
ISO/IEC 7816~4:1995(E~
--The blocking shall be continuous at the border between adjacent data objects to be integrated.
--The padding shall apply at the end of each data object to be integrated followed either by a data object not to be integrated or by no further data object.
The padding consists of one mandatory byte valued to '80' followed, if needed, by O to k-1 bytes set to '00', until the respective data block is filled up to k bytes. Padding for authentication has no influence on transmission as the padding bytes shall not be transmitted.
The mode of operation is ~cipher block chaining (see ISO/IEC 10116). The first input is the exclusive-or of the initial check block with the first data block. The first output results from the first input. The current input is the exclusive~r of the previous output with the current data block. The current output results from the current input. The final check block is the last output.
--Final stage--The final stage extracts a cryptographic checksum (first m bytes, at least 4) from the final check block.
Table 20 shows the cryptographic checksum data object.
Table 20--Cryptographic checksum data object Cryptograchlc checksum (at least 4 bytes)
5.6.3.2 Digital signature data object
The digital signature computation is typically based upon asymmetnc cryptographic techniques. There are two types of digital signatures:
--digital signature with appendix,
--digital signature giving message recovery.
The computation of a digital signature wlth appendix implies the use of a hash function (see ISO/IEC 10118). The data input either consists of the value of the digital signature input data object (see table 21), or is determined by the mechanism defined in 5.6.3.1.
The computation of a digital signature giving message recovery (see ISO/IEC 9796) does not imply the use of a hash function. However, according to the needs of the application, a hash code may be present as a part of the recovered message which may itself be sER-TLv-coded.
Table 21 shows digital signature related data objects.
Tablo 21--Digital signature related data objects
Ta~ Value
'9A', 'BA' Digital signature input data '9E' Digital signature
(o ISO/IEC
5.6.4 Data objects for confidentiality
Data objects for confidentiality are intended for carrying a cryptogram which plain value consists of one of the following 3 cases:
--BER-TLV, including SM-related data objects, --BER-TIV, not including SM-related data objects, --not BER-TLV coded data
Padding has to be indicated when the plain value consists of not BER-TLV coded data. When padding is applied but not indicated, the rules defined in 5.6.3.1 shall apply.
Table 22 shows the data objects for confidentiality.
Table 22--Data objects for confidentiality
Tag Value
Cryptogram, the plain value consisting of '82, '83' --BER-TLV, Includlng SM-related data objects 84, ~85~ --BER-TLV but not SM-related data objects
861, 87~ Padding Indicator bvte (see table 23) followed by cryptogram (plain value not coded in BER-TLV)
Every data object for confidentiality may use any cryptographic algorithm and any mode of operation, owing to an appropriate algonthm reference (see 5.6.5.1). In the absence of an algonthm reference and when no mechanism is implicitly selected for confidentiality, a default mechanism shall apPlY
For the computation of a cryptogram which is preceded by the padding indicator, the default mechanism is a block cipher in 'electronic code book~ mode (see ISO/IEC 10116). The use of a block cipher may Involve padding. Padding for confidentiality has an influence on transmission, the cryptogram (one or more blocks) is longer than the plain text.
Table 23 shows the padding Indicator byte.
Table 23--Padding indicator byto
Value Meaning oo~ --No furthemndlcatlon ~01~ --Padding as defined In 5 6.3.1 ~02 ~ --No padding '80~ to ~8E~ --Proprietary Other values are RFU
For the computation of a cryptogram not preceded by a padding indicator byte, the default mechanism is a stream cipher with an exclusive-or. In this case, the cryptogram is the exclusive-or of the string of data bytes to be concealed with a concealing string of the same length. Concealment thus requires no padding and the data objects concealed in the value field are recovered by the same operation.
5.6.5 Auxiliary security data objects
An algorithm, a key and, possibly, initial data may be selected for each security mechanism
--implicitly, i.e., known before issuing the command.
--explicitly, by control references nested in a control reference template.
Each command message may carry a response descriptor template fixing the data objects required in response. Inside the response descriptor, the security mechanisms are not yet applied; the receiving entity shall apply them for constructing the response
5.6.5.1 Control references
Table 24 shows the control reference lemplates
Table 24--Control reference templates Meaning
'B4~MB5~ |--Tempiate valld for cryptograpnlc cnecksum B6 ' , ' B 7 '
--Template valld for digltal slgnature --TemDIate valid for confidentlalitv
The last possible position of a control reference template is just before the first data object to which the referred mechanism applies. For example, the last possible position of a template for cryptographic checksum is just before the first data object integrated in the computation
Each control reference remains valid until a new control reference is provided for the same mechanism. For example, a command may fix control references for the next command.
Each control reference template is intended for carrying control reference data objects (see table 25): an algorithm reference, a file reference, a key reference, an initial data reference and, only in a control reference template for confidentiality, a cryptogram contents reference.
The algorithm reference fixes an algorlthm and its mode of operation (see ISO/IEC 9979 and 10116). Structure and coding of the algorithm reference are not defined in this part of ISO/IEC 7816.
The file reference denotes the file where the key reference is valid. If no file reference is present, then the key reference is valid in the current DF.
The key reference identifies the key to be used.
The initial data reference, when applied to cryptographic checksums, fixes the initial check block. If no initial data reference is present and no initial check block is implicitly selected, then the null block shall be used. Moreover, before transmitting the first data object for confidentiality using a stream cipher, a template for confidentiality shall provide auxiliary data for initializing the computation of the string of concealing bytes.
IS~ 10
The cryptogram contents reference specifies the content of the cryptogram (e.g., secret keys, initial password. control words). The first byte of the value field is named the cryptogram descriptor byte and is mandatory. The range '00' to '7F' is RFU. The range '80' to 'FF' is proprietary.
Table 25--Control reference data objects
Tag Value 80 Algorithm reference File reference 81 --file identifier or path 82' --D' name Key reference '83' --for direct use '84 Initial data reference ù Initial check block 85' --L=0. null block 86 --L=0, chaining block '87' --L=0, prevlous initial value block plus one L=k, initlal value blocK ù Auxiliary data '88 --L=O, previous exchanged challenge plus one L~O, no funher Indication 89 to --L=O, index of a propnetary data element '8D L-O, value of a croprletary data element
'8E~ Cryptogram contents reference 5.6.5.2 Response descriptor
The response descriptor template, if present in the data field of the command APDU, shall fix the structure of the corresponding response Empty data objects shall list all data needed for producing the response.
The securitv items (algonthms. keys and initial data) used for processing the data field of a command message may be different from those used for producing the data field of the subsequent response message.
The following rules shall apply.
--The card shall fill each empty prlmitive data object.
--Each control reference template present in the response descriptor shall be present in the response at the same place with the same control references for algorithm, file and key. If the response descriptor provides auxiliary data. then the respective data object shall be empty in the response. If an empty reference data object for auxiliary data is present in the response descriptor, then it shall be full in the response.
--By the relevant security mechanisms, with the selected security items, the card shall produce all the requested security mechanism data objects.
~SO/IE~ 7816-4:1995 ~E)
Table 26 shows the response descnptor template.
Table 26--Response descriptor template ' BA , ' B B ' ResrJonse descrlDIor 5.6.6 SM status conditions
In any command using secure messaging, the following specific error conditions may occur.
--SW1 = '69' with SW2 =
ù '87': Expected SM data objects missing.
ù'88': SM data obiects incorrect.
6 Basic interindustry commands
It shall not be mandatory for all cards comDIying to this part of ISO/IEC 7816 to support all the described commands or all the options of a supported command.
When international interchange is required, a set of card system services and related commands and options shall be used as defined in clause 9
Table 11 provides a summary of the commands defined in this part of ISO/IEC 7816
The impact of secure messaging (see 5.6) on the message structure is not described in this clause.
The list of error and warning conditions given in each clause 6.X.5 is not exhaustive (see 5.4 5).
6.1 READ BINARY command 6.1.1 Definition and scope
The flEAD BINARY response message gives IPart of I the content of an EF with transparent structure.
6.1.2 Conditional usage and security
When the command contains a valid short EF identifier, it sets the file as current EF.
The command is processed on the currently selected EF. The command can be performed only if the security status satisfies the security attributes defined for this EF for the read function.
~) ISO/IEC
The command shall be aborted if it IS applied to an EF without transparent structure.
6.1.3 Command message Table 27 -- READ BINARY command APDU
CLA As defined In 5 4.1 INS ' B0' P1-P2 See text below Lc field Empty Data field Empty Le fieid Number of bytes to be read
If b8=1 in P1, then b7 and b6 of P1 are set to 0 (RFU bits). b5 to bl of P1 are a short EF identifier and P2 is the offset of the first byte to be read in data units from the beginning of the file.
If b8=0 in P1, then P1 ll P2 is the offset of the first byte to be read in data units from the beginning of the file.
6.1.4 Response message ~nominal case~
If the Le field contains only zeroes, then within the limit of 256 for short length or 65 536 for extended length, all the byte- until the end of the file should be read.
Table 28-- READ BINARY response APDU Data fleid Data read (Le bytes ~;W1-SW7 StAtllC hVtf'C 6.1.5 Status conditinns
The following specific warnlng conditions may occur.
--SW1 = '62' with SW2 =
ù'81': Part of returned data may be corrupted.
ù'82': End of file reached before reading Le bytes.
The following specific error conditions may occur.
--SW1 = '67' with SW2 =
ù '00': Wrong length (wrong Le field).
--SW1 = '69' with SW2 =
ù '81': Command incompatible with file structure.
ù '82': Security status not satisfied.
ù '86': Command not allowed (no current EF).
--SW1 = '6A' with SW2 =
ù 181': Function not supported.
ù '82': File not found.
--SW1 = '6B' with SW2 =
ù'00': Wronq Darameters (offset outside the EF).
--SW1 = '6C' with SW2 =
ù 'XX': Wrong length (wrong Le field; 'XX' indicates the
exact length).
6.2 WRITE BINARY command
6.2.1 Definition and scope
The WRITE BINARY command message initiates the writing of binary values into an EF.
Depending upon the file attributes, the command shall perform one of the following operations:
--the logical OR of the bits already present in the card with the bits given in the command APDU (logical erased state of the bits of the file is 0),
--the logical AND of the bits already present in the card with the bits given in the command APDU (logical erased state of the bits of the file is 1),
--the one-time write in the card of the bits given in the command APDU.
When no indication is given in the data coding byte (see table 86), the logical OR behavior shall apply.
6.2.2 Conditional usage and security
When the command contains a valid short EF identifier, it sets the file as current EF
The command is processed on the currently selected EF. The command can be performed only if the security status satisfies the securitv attributes for the write functions.
Once a WRITE BINARY has been applied to a data unit of a one-time write EF any further write operation referring to this data unit will be aborted if the content of the data unit or the logical erased state indicator (if any) attached to this data unit is different from the logical erased state.
The command shall be aborted if it is applied to an EF without transparent structure.
6.2.3 Command message
Table 29--WRITE BINARY command APDU
CLA As defined in 5.4.
I NS ~ D0 '
Pl-P2 See text below Lc field Length of the subsequent data field Data field String of data unlts to be wntten Le field EmDtv
If b8=1 in P1, then b7 and b6 of P1 are set to 0 (RFU bits), b5 to b1 of P1 are a short EF identifler and P2 is the offset of the first byte to be written ir oata lln(ts from the beginning of the file.
If b8=0 in P1, then P1 ll P2 is the offset of the first byte to be written in data units from the beginning of the file.
6.2.4 Response message (nominal case) Table 30 -- WRITE BINARY response APDU DAta field I EmDtv SW1 -SW2 Status bvfes 6.2.5 Status conditions
The following specific warning condition may occur.
--SW1 = '63' with SW2 =
ù 'CX': Counter (successful writing, but after using an
internal retry routine, 'X' ~ '0' indicates the number of
retries: 'X' = '0' means that no counter is provided).
The following specific error conditions may occur --SW1 = '65' with SW2 =
ù '81': Memory failure (unsuccessful writing).
--SW1 = '67' with SW2 =
ù '00': Wrong lenqth (wrong L,~ field).
--SW1 = '69' with SW2 =
ù '81': Command incompatible with file structure.
ù '82': Security status not satisfied.
ù '86': Command not allowed (no current EF).
--SW1 = '6A' with SW2 =
ù '81': Function not supported
ù'82': File not found.
--SW1 = '6B' with SW2 =
ù'00': Wrong parameters (offset outside the EF).
6.3 UPDATE BINARY command 6.3.1 Definition and scope
The UPDATE BINARY command message initiates the update of the bits already present in an EF with the bits given in the command APDU.
6.3.2 Conditional usage and security
When the command contains a valid short EF identifier. it set.s the file ~.s el~rrent EF
The command is processed on the currently selected EF. The command can be performed only if the security status satisfies the security attributes for the update function.
The command shall be aborted if it is applied to an EF without transparent structure.
ISO/IEC 7816~4:1995~E) 6.3.3 Command message Table 31 --UPDATE BINARY command APDU CLA As defined in 54.1
INS ' D6 '
P1-P2 See text below Lc field Length of the subsequent data field Data field String of data unitr to be updated Le f ield
If b8=1 in P1, then b7 and b6 of P1 are set to 0 (RFU bits), b5 to bl of P1 are a short EF identifier and P2 is the offset of the first byte to be updated in data units from the beginning of the file.
If b8=0 in P1
then P1 ll P2 is the offset of the first byte to be updated in data units from the beginning of the file.
6.3.4 Response message ~nominal case) Table 32--UPDATE BINARY response APDU Data field Em pty SW1-SW2 | Status bvtes 6.3.5 Status conditions The following specific warning condition may occur --SW1 = '63' with SW2 =
ù 'CX': Counter (successful updating, but after using an
internal retry routine, 'X' ~ '0' indicates the number of
retries; 'X' = '0' means that no counter is provided).
The following specific error conditions may occur.
--SW1 = '65' with SW2 =
ù '81': Memory failure (unsuccessful updating).
--SW1 = '67' with SW2 =
ù '00': Wrong length (wrong Lc field).
--SW1 = '69' with SW2 =
ù '81': Command incompatlble with file structure.
ù'82': Security status not satisfied.
ù'86': Command not allowed (no current EF).
--SW1 = '6A' with SW2 =
ù '81': Function not suDported.
ù '82': File not found.
--SW1 = '6B' with SW2 =
ù '00': Wrong parameters (offset outside the EF).
6.4 ERASE BINARY command 6.4.1 Definition and scope
The ERASE BINARY command message sets IPart ofl the content of an EF to its logical erased state, sequentially, starting from a given offset.
18
6.4.2 Conditional usage and security
When the command contalns a valid short EF identifier, it sets the file as current EF
The command is processed on the currently selected EF. The command can be performed only if the security status satisfies the securitv attributes for the erase function.
The command shall be aborted if it is applied to an EF without transparent structure.
6.4.3 Command message Table 33-- ERASE BINARY command APDU
.
CLA As defined In 5 4.1
I NS 'OE '
P'-P2 See text below Lc field Empty or '02' Data field See text below Le field Empty
If b8=1 in P1, then b7 and b6 of P1 are set to O (RFU bits). b5 to bl of P1 are a short EF identifier and P2 is the offset of the first byte to be erased in data unlts from the beainnina of the file.
If b8=0 in P1, then P1 ll P2 is the offset of the first byte to be erased in data units from the beainnina of the file.
If the data field is present, it codes the offset of the first data unit not to be erased. This offset shall be higher than the one coded in P1-P2. When the data field is empty, the command erases up to the end of the file.
6.4.4 Response message (nominal case~
Table 34--ERASE BINARY response APDU Data fleld SW1 -SW2 Empty Status bvtes
6.4.5 Status conditions
The following specific warning condition may occur.
--SW1 = '63' with SW2 =
ù 'CX': Counter (successful erasing, but after using an internal retry routine, 'X' ~ 'O' indicates the number of retries; 'X' = 'O' means that no counter is crovided).
The following specific error conditions may occur.
--SW1 = '65' with SW2 =
ù'81': Memory failure (unsuccessful erasing).
--SW1 = '67' with SW2 =
ù '00': Wrong length (wrong Lr field).
--SW1 = '69' with SW2 =
ù'81': Command incompatible with file structure.
ù'82': Security status not satisfied.
ù '86': Command not allowed (no current EF).
--SW1 = '6A' with SW2 =
ù'81': Function not supported.
ù'82': File not found.
--SW1 = '6B' with SW2 =
ù'00': Wrong parameters (offset outside the EF).
6.5 READ RECORDIS ) command 6.5.1 Definition and scope
The READ RECORD(S) response messag~ of the specified record(s) lor the be- ~ rA art of one recordl of an EF.
~r'~ contents 6.5.2 Conditional usage and security
The command can be performed only if the security status satisfies the security attributes for this EF for the
r ~ r1 fllnrtir~n
If an EF is currently selected at the time of issuing the command, then this command may be processed without identification of this file.
When the command contains a valid short EF identifier, it sets the file as current EF and resets the current record pointer.
The command shall be aborted If applied to an EF without record structure.
6.5.3 Command message Table 35--READ RECORD(S) command APDU
CLA As deflne~ In 5.4 l NS ' B 2 ' Pl Record number o, record identifier of the first record to be read ('00' indicates the current record) P2 Reference comrol. accordlng to table 36 Lc field Empty Data field Empty Le field Number of bytes to be read
Table 36--Coding of the reference control P2 b8 b7 bS b5 b4 b3 b2 bl Meaning
O o O O O ~ Currenai selected EF
x x x x x - - - --Short EF identifier (not all equal) RFU -----1 x x Usage of record number in P1 -----1 O O --Read record P1
-----1 o 1 --Read all records from P1 up to the last
-----1 1 o --Read all records from the last up to P1
-----1 1 1 RFU
.
-----O x x Usage of record identifier in P1 ----O O O --Read first occurrence ----O O 1 --Read last occurrence ----o 1 o --Read next occurrence -----O 1 I --Read prevlous occurrence
6.5.4 Response message (nominal case)
If the Le field contains only zeroes, then depending on b3b2b1 of P2 and within the limit of 256 for short length or 65 536 for extended length, the command should read completely
--either the single requested record,
--or the requested sequence of records.
Table 37 --READ RECORD(S~ response APDU Data fleld | L, (may be equal to Le) bytes. see table 38 SW1-SW2 I Status bvtes
When the records are SIMPLE-TLV data objects (see 5.4.4). table 38 illustrates the format of the data field of the response message.
Table 38-1--Data field of the response when readino for one record
Tn 1 byte Case a--Partial read of one record
Ln or 3 bytes
First data bytes of the record Le bytes
This case applies when the Le field does not contain only ~eroes .
Case b--ComDIete read of one record Ln 1 or 3 bvtes Whole data bytes of the record Ln bytes
This case applies when the Le field contains only zeroes.
!SO!!Er 78~4: ~995 !E!
Table 38-2--Data field of the response when readinn for several records
Case c--Partial read of a record sequence
Recora # n Tnll L~dlVn First bytes of record # n+m Tn,mll Ln.mllVn.m
This case applies when the Le field does not contain only zeroes.
Case d--Read multiple records UD to the file end Record # n Tnll Lnlivn Record # n+m Tn~.mllLnlmllVnlm This case applies when the Le field contains only zeroes
The comparison of the length of the data field with its TLV structure gives the nature of the data: the unique record (read one record) or the last record (read all records~ is incomplete, complete or padded.
NOTE--If TLV coding IS not used, then the read-all-records function results In recelvlng several records without standard delimitation r.,f tha re~r~rr!~
~i 5 5 ~;tat~c ennditinnc
The following specific warning conditions may occur.
--SW1 = '62' with SW2 =
ù'81': Part of returned data may be corrupted.
ù'82': End of record reached before Le bytes.
The following specific error conditions may occur.
--SW1 = '67' with SW2 =
ù'00': Wrong length (empty Le field).
--SW1 = '69' with SW2 =
ù '81': Command incompatible with file structure.
ù'82': Security status not satisfied.
--SW1 = '6A' with SW2 =
ù '81': Function not supported.
ù'82': File not found.
ù'83': Record not found.
--SW1 = '6C' with SW2 =
ù 'XX': Wrong length (wrong Le field; 'X)(' indicates the
exact length).
6.6 WRITE RECORD command 6.6.1 Definition and scope
The WRITE RECORD command message initiates one of the following operations:
20
--the write once of a record;
--the logical OR of the data bytes of a record already present in the card with the data bytes of the record given in the command APDU;
~I~U/IC~.
--the logical AND of the data bytes of a record already present in the card with the data bytes of the record given in the command APDU.
When no indication is given in the data coding byte (see table 86), the logical OR operation shall apply.
When using current record addressing, the command shall set the record pointer on the successfully written rr~er)rri
6.6.2 Conditional usage and security
The command can be performed only if the security status satisfies the security attributes for this EF for the write f unctions.
If an EF is currently selected at the time of issuing the command, then this command may be processed without identification of this file.
When the command contains a valid short EF identifier, it sets the file as current EF and resets the current record pointer.
The command shall be aborted if applied to an EF without record structure.
The "previous' option of the command (P2 = xxxxxO11), applied to a cyclic file, has the same behavior as APPEND RECORD.
6.6.3 Command messa,r~e
Table 39 -- WRITE RECORD command APDU
CLA As defined In 5.4 NS ' D 2 ' Pl Pl = ~00~ designates the current record. P1 ~ '00Ms the number of the specified record. P2 According to table 40 Lc field Length of the subsequent data field Data field Record to be wntten Le field Empty
.
Table 40--Codinrg of the reference control P2
.
b8 b7 b6 b5 b4 b3 b2 b1 Meaning O O O O O ~ Currently selected EF x x x x x - - - --Short EF identlfier (not all equal)
-----o O o --First record -----O O 1 --Last recora -o 1 C --Next record
3 1 1 --Previous record -----1 o O --Record number given in P1
~_ RFU
When the records are SIMPLE-TLV data objects (see 5.4.4), table 41 illustrates the format of the data field of the command messaqe.
Table 41 --Data field of the command ComDIete write of one record Tn | Ln | Whole data bvtes of the record | 1 byte | 1 or 3 bytes | Ln bytes 6.6.4 Response message Inominal case) Table 42-- WRITE RECORD response APDU Data field EmPty SW1-SW2 Status bytes 6.6.5 Status conditions
The following specific warning condition may occur.
--SW1 = '63' with SW2 =
ù 'CX': Counter (successful writing, but after using an
internal retry routine, 'X' 3t '0' indicates the number of
retries: 'X' = '0' means that no counter is Drovided).
The following specific error conditions may occur.
--SW1 = '65' with SW2 =
ù'81': Memory failure (unsuccessful writing).
--SW1 = '67' with SW2 =
ù '00': Wrona lencth (emDtv L~ field)
--SW1 = '69' with SW2 =
ù '81': Command incompatible with file structure.
ù'82': Security status not satisfied.
ù '86': Command not allowed (no current EFI
--SW1 = '6A' with SW2 =
ù '81': Function not supported.
ù'82': File not found
ù'83': Record not found.
ù'84': Not enough memory space in the file.
ù'85': Lr inconsistent with TLV structure.
6.7 APPEND RECORD command 6.7.1 Definition and scope
The APPEND RECORD command message initiates either the appending of a record at the end of an EF of linear structure or the writing of record number 1 in an EF of cyclic structure (see 5.1.4).
The command shall set the record pointer on the successfully appended record.
6.7.2 Conditional usage and security
The command can be performed only if the security status satisfies the securitv attributes for this EF for the append function
l so \~
f an EF is currently selected at the time of issuing the command, then this command may be processed without identification of this file.
When the command contains a valid short EF identifier, it sets the file as current EF and resets the current record pointer.
The command shall be aborted if applied to an EF without r~cnr~ ~tnlct~lre
NOTE--If this command is apolied to an EF of cyclic structure full of records, then the record wlth the hlghest record number is replaced. This record becomes record number 1.
6.7.3 Command message Table 43 -- APPEND RECORD command APDU
C LA As defined In 5 4.1 I NS ' E2 ' Fl Only P1 = ~00~ is valid P2 According to table 44 Lc field Length of the subsequent data field Data field Record to be appended Le f ield E m pty
Table 44--Coding of the reference control P2 b8 b7 b6 b5 b4 b3 b2 b1 | Meaning
O O G o O O O O --Currently selected EF x x x x x O O O --Short EF identifier (not all equall
Any other value RFU
When the records are SIMPLE-TLV data objects (see 5.4.4), table 45 illustrates the format of the data field of the command message
Table 45--Data field of the command ComDIete aDDend of one record Tn 1 byte
Ln or 3 bvtes
Whole ~ata bytes of the record Ln bytes
6.7.4 Response message (nominal case~
Table 46--APPEND RECORD response APDU Data field Empty SW1-SW2 Status bytes
6.7.5 Status conditions
The following specific warning condition may occur.
--SWl = '63' with SW2 =
ù 'CX': Counter (successful appending, but after using an internal retry routine, 'X' ~ '0' indicates the number of retries; 'X' = '0' means that no counter is provided).
I~U/lt ~ 4: lYY:> ~t~
The following specific error conditions may occur.
--SW1 = '65' with SW2 =
ù '81': Memory failure (unsuccessful appending)
--SW1 = '67' with SW2 =
ù '00': Wrong length (empty L~ field).
--SW1 = '69' with SW2 =
ù '81': Command incompatible with file structure.
ù '82': Security status not satisfied.
ù '86': Command not allowed (no current EF)
--SW1 = '6A' with SW2 =
ù '81': Function not supported.
ù '82': File not found.
ù '84': Not enough memory space in the file.
ù '85' Lc inconsistent with TL\I structure.
6.8 UPDATE RECORD command 6.8.1 Definition and scope
The UPDATE RECORD command message initiates the updating of a specific record with the bits glven In the n~mm~nrJ APr~J
When using current record addressing, the command shall set the record pointer on the successfully updated record .
6.8.2 Conditional usage and security
The command can be performed only if the security status satisfies the security attributes for this EF for the update function.
If an EF is currently selected at the time of issuing the command, then this command may be processed without identification of this file.
When the command contains a valid short EF identifier, it sets the file as current EF and resets the current record cointer.
The command shall be aborted if applied to an EF without record structure.
When the command applies to an EF with linear fixed or cyclic structure, then it shall be aborted if the record length is different from the length of the existing record.
When the command applies to an EF with linear variable structure, then it may be carried out when the record length is different from the length of the existing record.
The ùprevious~ option of the command (P2 = xxxxx011), applied to a cyclic file, has the same behavior as APPEND RECORD.
6.8.3 Command message Table 47 -- UPDATE RECORD command APDU
CLA As defined In 5.4.1 -I NS ' DC ' Fl P1 = '00' deslgnates the current record P1 ~ '00' is the number of the specified record F2 According to table 48 L, field Length of the subsequent data field Data field Record to be updated Le field Empty
Table 48--Coding of the reference control P2
b8 b7 b6 b5 b4 b3 b2 bl Meaning O O O O O ~ Currently selected EF x x x x x - - - --Short EF identlfier (not all equal) O o O --First record
-----O O 1 --Last record -----O 1 O --Next record -----O 1 1 --Prevlous record ----1 o O --Record number given in P1
Anv other value RFU
When the records are SIMPLE-TLV data objects (see 5.4.4), table 49 illustrates the format of the data field of the command messaqe.
Table 49--Data field of the command Complete update of one record 1 byte
Ln or 3 bytes
Whole data bytes of the record Ln bytes 6.8.4 Response message (nominal case~ Table 50-- UPDATE RECORD response APDU
Data field I Emr.)tv SW1 -SW2
Status bvtes
6.8.5 Status conditions
The following specific warning condition may occur.
--SW1 = '63' with SW2 =
ù 'CX': Counter (successful updating, but after using an internal retry routine, 'X' ~ '0' indicates the number of retries; 'X' = '0' means that no counter is provided).
The following specific error conditions may occur.
--SW1 = '65' with SW2 =
ù '81': Memory failure ~unsuccessful updating).
--SW1 = '67' with SW2 =
ù '00': Wrong length (empty L~ field).
--SW1 = '69' with SW2 =
ù '81': Command incompatible with file structure
ù '82': Security status not satisfied.
ù '86': Command not allowed (no current EF)
--SW1 = '6A' with SW2 =
ù'81': Function not supported.
ù'82': File not found.
ù'83': Record not found.
ù'84': Not enough memory space in the file.
ù'85': L,~ inconsistent with TLV structure.
6.9 GET DATA command
6.9.1 Definition and scope
The GET DATA command is used for the retrieval of one primitive data object, or the retrieval of one or more data objects contained in a constructed data object, within the current context (e.g., application-specific environment or current DF~.
6.9.2 Conditional usage and security
The command can be performed only if the security status satisfies the security conditions defined by the application within the context for the function.
6.9.3 Command message
Table 51 -- GET DATA command APDU
CLA As defined In 5 4.1 I NS ~ CA ~ P1-P2 See table 52 Lc field Empty Data field Empty Le field Number of bytes expected in response
Table 52--Coding of the parameters P1-P2
Value Meaning ~0000' to '003F' RFU ~0040~ to 'OOFF' BER-TLV tag (1 byte) in P2 ~0100' to ~01FF' Applicatlon data (proprietary coding) ~0200' to '02FF' SIMPLETLV tag In P2 ~0300~ to '3FFF' RFU ~dOOO~ to ~FFFF~ BER-TLV tag (2 bytes) in P1-P2
Get application data
ù When the value of P1-P2 lies in the range from '0100' to 'OlFF', the value of P1-P2 shall be an identifier reserved for card internal tests and for proprietary services meaninqful within a aiven aDDIication context.
Get data objects
ù When the value of P1-P2 lies in the range from '0040' to 'OOFF', the value of P2 shall be a BER-TLV tag on a single byte. The value 'OOFF' is reserved for obtaining all the common E~ER-TLV data objects readable in the context.
ù When the value of P1-P2 lies in the range from '0200' to '02FF', the value of P2 shall be a SIMPLE-TLV tag. The value '0200' is RFU. The value '02FF' is reserved for obtaining all the common SIMPLE-TLV data objects readable in the context
ù When the value of P1-P2 lies in the range from '4000' to 'FFFF', the value of P1-P2 shall be a BER-TLV tag on two bytes. The values '4000' and 'FFFF' are RFU.
When a primitive data object is requested, the data field of the response message shall contain the value of the corresponding primitive data object.
When a constructed data object is requested, the data field of the response message shall contain the value of the constructed data object, i.e., data objects including their tag, length and value.
6.9.4 Response message (nominal case~
If the Le field contains only zeroes, then within the limit of 256 for short length or 65 536 for extended length, all the required information should be returned.
Table 53--GET DATA response APDU L, ImaY be equal to Le) bytes ~W1-~WZ I Status bytes Data field 6 9 5 Statlls conditions The following specific warning condition may occur --SW1 = '62' with SW2 =
ù '81': Part of returned data may be corrupted.
The followinq specific error conditions may occur.
--SW1 = '67' with SW2 =
ù '00': Wrong length (empty L,? field).
--SW1 = '69' with SW2 =
ù '82': Security status not satisfied.
ù '85': Conditions of use not satisfied.
--SW1 = '6A' with SW2 =
ù '81': Function not supported.
ù '88': Referenced data (data objects) not found.
--SW1 = '6C' with SW2 =
ù 'XX': Wrong length (wrong Le field; 'XX' indicates the
exact length).
ISO!IEC 781~4: ~995 !E!
6.10 PUT DATA command 6.10.1 Definition and scope
The PUT DATA command is used for storing one primitive data object, or one or more data objects contained in a constructed data object, within the current context (e.g., application-specific environment or current DF). The exact storing functions (writing once and/or updating and/or appending) are to be induced by the definition or the nature of the data objects.
NOTE--The command could be used, for example. to update data obiects.
6.10.2 Conditional usage and securit.y
The command can be performed only if the security status satisfies the security conditions defined by the application within the context for the function(s~
6.10.3 Command messaae Table 54 -- PUT DATA command APDU
CLA As defined In 5 4.1 I NS ~ DA' P1-P2 See table 55 Lc field Length of the subsequent data field
Data field Parameters and data to be wntten Le field E m pty Table 55--Coding of the parameters P1-P2
Value Meaning ~oOOO~ to ~003F' RFU
~0040' to ~OOFF' BER-TLV tag (1 bytel Ir P2 ~0100' to '01 FF~ Application data (propnetary coding) '0200' to '02FF' SIMPLE TLV tag in P2
~0300~ to '3FFF' RFU
~4000' to 'FFFF' aER-TLv tag (2 bytes) in P1-P2 Store application data
ù When the value of P1-P2 lies in the range from '0100' to 'OlFF', the value of P1-P2 shall be an identifier reserved for card internal tests and for proprietary services meaningful within a given application context.
~g iSO/iEC
Store data objects
ù When the value of P1-P2 lies in the range from '0040' to 00FF', the value of P2 shall be a BER-TLV tag on a single byte. The value 'OOFF' is reserved for indicating that the data field carries BER-TLV data objects.
ù When the value of P1-P2 lies in the range from '0200' to '02FF', the value of P2 shall be a SIMPLE-TLV tag. The value '0200' is RFU. The value '02FF' is reserved for indicating that the data field carries SIMPLE-TLV data objects.
ù When the value of P1-P2 lies in the range from '4000' to 'FFFF', the value of P1-P2 shall be a BER-TLV tag on two bvtes. The values '4000' and 'FFFF' are RFU.
When a primitive data object is provided, the data field of the command message shall contain the value of the corresponding primitive data object.
When a constructed data object is provided, the data field of the command message shall contain the value of the constructed data object, i.e., data objects including their tag, length and value.
6.10.4 Response message Inominal case)
Table 56--PUT DATA response APDU Data fleld tmpty ~WI-SW~ I Status bytes
6.10 . 5 Status conditions
The following specific warning condlllcr.s ~,ay occur.
--SW1 = '63' with SW2 =
ù 'CX': Counter (successful stonng, but after using an
internal retrv routine, 'X' . 'O' indlcates the number of retries; X' = 'O' means that no counter is provided).
The following specific error conditions may occur.
--SW1 = '65' wlth SW2 =
ù '81': Memory failure ~unsuccessful storing).
--SW1 = 67' with SW2 =
ù '00': Wrong length ~wrong Lc field).
--SW1 = '69' with SW2 =
ù '82': Security status not satisfied.
ù '85': Conditions of use not satisfied.
--SW1 = '6A' with SW2 =
ù '80': Incorrect parameters in the data field.
ù '81': Function not supported.
ù '84': Not enough memory space in the file.
ù '85 Lc inconsistent with TLV structure.
6.11 SELECT FILE command 6.11.1 Definition and scope
A successful SELECT FILE sets a current file within a logical channel (see 5.5). Subsequent commands may implicitly refer to the current file throuqh that loqical channel.
Selecting a DF (which may be the MF) sets it as current DF. After such a selection, an implicit current EF may be referred to through that logical channel.
Selecting an EF sets a pair of current files: the EF and its parent file.
After the answer to reset, the MF is implicitly selected through the basic logical channel (see 5.5.2), unless specified differently in the historical bytes (see 8) or in the initial data string (see 9).
NOTE--A direct selection by DF name can be used for selece inq appllcatlons reqlstered accordlnq to part 5 of ISO/IEC 7816.
6.11.Z Conditional usa~e and security
The following conditions shall apply to each open logical channel.
Unless otherwise specified, the correct execution of the command modifies the security status (see 5.2.1 ) according to the following rules.
--When the current EF is changed, or when there is no current EF, the security status, if any, specific to a former current EF is lost.
--When the current DF is a descendant of, or identical to the former current DF, the security status specific to the former current DF is maintained.
--When the current DF is neither a descendant of, nor identical to the former current DF, the security status specific to the former current DF is lost. The security status common to all common ancestors of the previous and new current DF is malntained.
6.11.3 Command message Table 57 -- SELECT FILE command APDU
CLA As defined In 5 4.1 INS ~A4 ~ Pl Selection comroi, see table 58 P2 Selection optlons, see table 59 Lc field Empty or length of the subsequent data field Data field If present, according to P1-P2, --file identifier --path from the MF --path from the current DF --DF name Le field Empty or maximum length of data expected in response
.
Table 58--Coding of the selection control P1
.
b8 b7 b~i bS b4 b3 b2 bl Meaning
O o o O O O x x Selection by file identifier O O O O O O O O --Select MF, DF or EF (data field = identifier or empty) O O O O O O O 1 --Select child DF (data field = DF identifier)
O O O O O O 1 O --Select EF under current DF (data field = EF identifier) O O O O O O 1 1 --Select parent DF of the current DF (empty data field) O O o O O 1 x x Selection by DF name O O O O O 1 O O --Direct selection by DF name (data field = DF name) O O O O O 1 O 1 RFU O O O O O 1 1 O RFU O O O O O 1 1 1 RFU
.
O O o 0 1 o x x Selection by path Isee 5.1.21
O O O O 1 O O O --Select from MF (data field = path without the identifier of the MF) O O O O 1 O O 1 --Select from current DF (data field = path without the Identl8er of the current DF) O O O O 1 O 1 O RFU O O O O 1 O 1 1 RFU Any other value RFU
Cr ~r~e
ù-~V ~ /0 ~ C~
When P1 = '00', the card knows either because of a specific coding of the fi)e identifier or because of the context of execution of the command if the file to select is the MF, a DF or an EF.
When P1-P2 = '0000', if a file identifier is provided, then it shall be unique in the following envlronments:
--the immediate children of the current DF, --the parent DF, --the immediate children of the parent DF
If P1-P2 = 'OOOO' and if the data field is empty or equal to '3FOO', then select the MF.
When P1 = '04', the data field is a DF name, possibly right truncated. When supported, successive such commands with the same data field shall select DFs whose names match with the data field, i.e., start with the command data field. If the card accepts the SELECT FILE command with an empty data field, then all or a subset of the DFs can be successively selected.
NOTE--See 8.3.6 for the selection methods supponed by the card.
Table 59--Coding of the selection options P2
b8 b7 b6 b5 b4 b3 b2 b1 Meaning O o o O - - o o --First or on~y occurrence O O O O - - O 1 --Last occurrence O O O O - - 1 O --Next occurrence O O O O - - 1 1 --Prevlous occurrence O O O O x x - - File control information option (see 5.1.5) C O O O O O - - --Return FCI, optional template O O O O O 1 - - --Return FCP template o o o o 1 o - - --Return FMD tempiate
Any other value RFU
6.11.4 Response messa~e ~nominal case~
If the Le field contains only zeroes. then within the limit of 256 for short length or 65 536 for extended length, all the bytes corresponding to the selection option should be r~tllrnf?fi
Table 60 -- SELECT FILE response APDU
Data field Informatlon accordlng to P2 (at most Le bytes)
SW1-SW2 Status bytes
6.11.5 Status conditions
The following specific warning conditions may occur.
--SW1 = '62' with SW2 =
ù'83': Selected file invalidated.
ù'84': FCI not formatted according to 5.1.5.
The following specific error conditions may occur.
--SW1 = '6A' with SW2 =
ù '81': Function not supported.
ù '82': File not found.
ù '86': Incorrect parameters P1-P2.
ù '87': Lc inconsistent with P1-P2.
~I~U/It~ 6.12 VERIFY command 6.12.1 Definition and scope
The VERIFY command initiates the companson in the card of the verification data sent from the interface device with the reference data stored in the card ~e.g., password).
6.12.2 Conditional usage and security
The security status may be modified as a resu)t of a comparison. Unsuccessful comparisons may be recorded in the card (e.g., to limit the number of further attempts Of the use of the reference data).
6.12.3 Command message
Table 61--VERIFY command APDU CLA As defined in 5.4.1 INS '20' F1 'OO' (other values are RFU) P2 Qualifier of the reference data. see table 62
Lc field Empty or length of the subsequent data field Data field Empty or verification data Le field Emptv Table 62--Coding of the reference control P2
b8 b7 b6 b5 b4 b3 b2 bl Meaning
o O O O O O O O --No ~nformanon Is glven O - - - - - - - --Global reference data (e.g., card password)
---------Specific reference data le.g.. DF speclfic password) -x x - - - - - 00 (other values are RFU) ---x x x x x --Reference data number
NOTES
F2 = ~OO' is reserved to Indicate that no panicular qualifier is u~d, in those cards where the VERIFY command references the secret data unambiguously
2 The reference data number may be for example a password number or a shon EF identifier.
3 When the body is empty, the command may be used either to retrieve the number 'Xl of further allowed retnes (SW1SW2 = ~63CX') or to check whether the verificaeon is not required (SW1-SW2 = '9OOO')
6.12.4 Response message ~nominal casel Table 63-- VERIFY response APDU Data field SW1 -SW2 Empty Status bytes
6.12.5 Status conditions
The following specific warning conditions may occur.
--SW1 = '63' with SW2 =
ù '00': No information r~iven (verification failedl.
ù 'CX': Counter (verification failed; 'X' indicates the number of further allowed retries).
The following specific error conditions may occur.
--SW1 = '69' with SW2 =
ù'83': Authentication method blocked.
ù'84': Referenced data invalidated.
--SW1 = '6A' with SW2 =
ù'86': Incorrect parameters P1-P2.
ù '88': Referenced data not found.
6.13 INTERNAL AUTHENTICATE command
6.13.1 Definition and scope
The INTERNAL AUTHENTICATE command initiates the computation of the authentlcatlon data by the card using the challenge data sent from the interface device and a relevant secret (e.g., a key) stored in the card.
When the relevant secret is attached to the MF, the command may be used to authenticate the card as a whole
When the relevant secret is attached to another DF, the command may be used to authenticate that DF.
6.13.2 Conditional usage and security
The successful execution of the command may be subject to successful completion of prior commands (e.g., VERIFY, SELECT FILE) or selections (e.g., the relevant secret).
If a key and an algorithm are currently selected when issuing the command, then the command may implicitly use the key and the algorithm
The number of times the command is issued may be recorded in the card to limit the number of further attempts of using the relevant secret or the algorithm.
6.13.3 Command messaoe
Table 64--INTERNAL AUTHENTICATE command APDU CLA As defined in 5.4 1 INS '88'
Pl Reference of the algorithm Ir the card
P2 Reference of the secret, see table 65 Lc field Length of the subsequent data field Data field Authentlcation related data ~e.g., challengel Le field Maxlmum number of bvtes expected in response
P1 = '00' indicates that no information is given. The reference of the algorithm is known either before issuing the command or is r rovided in the data field.
I~,o l?_
P2 = '00' Indicates that no information is given. The reference of the secret is known either before issuing the command or is Drovided in the data field
Table 65--Coding of the reference control P2 b8 b7 b6 b5 b4 b3 b2 b1 | Meaning O O O O O O O O --No informatlon Is glven O - - - - - - - --Global reference data (e.g., an MF specific key) ---------Specific reference data (e.g., a DF specific key) -x x - - - - - 00 (other values are RFU) ---x x x x x --Number of the secret
NOTE--The number of the secret may be for example a key number or a short EF identlfier.
6.13.4 Response message (nominal case) Table 66 -- INTERNAL AUTHENTICATE reswnse APDU Data field Authentlcatlon related data (e.g., response to ole challenge) SW1-SW2 Status bytes
NOTE--The response message may include data useful for further appllcation securitV functlons (e.g., random number).
6.13.5 Status conditions
The following specific error conditions may occur.
--SW1 = '69' with SW2 =
ù '84': Referenced data invalidated.
ù '85': Conditions of use not satisfied
--SW1 = '6A' with SW2 =
ù '86': Incorrect parameters P1-P2
ù'88': Referenced data not found.
6.14 EXTERNAL AUTHENTICATE command 6.14.1 Definition and scope
The EXTErlNAL AUTHENTICATE command conditionally updates the security status using the result (yes or no) of the computation by the card based on a challenge previously issued by the card (e.g., by a GET CHALLENGE command), a key possibly secret stored in the card and authentication data transmitted bv the Interface device.
6.14.2 Conditional usa~e and security
The successful execution of the command requires that the last challenge obtained from the card is valid.
Unsuccessful comparisons may be recorded in the card (e.g., to limit the number of further attempts of the use of the reference data).
aullt~ /~1~4: lYY5 (t) 6.14.3 Command messa~e Table 67 --EXTERNAL AUTHENTICATE command APDU CLA As defined In 54.1 INS '32 ' Pl Reference of the algorithm in the card F~2 Reference of the secret, see table 68 Lc field Empty or length of the subsequent data field Data field Empty or authentication related data (e.g., response to the challengei Le f ield Empty
P1 = '00' indicates that no information is given. The reference of the algorithm is known either before issuing the command or is provided in the data field.
P2 = '00' indicates that no information is given. The reference of the secret is known either before issuing the command or is provided in the data field.
Table 68--Coding of the reference control P2 b8 b7 b6 b5 b4 b3 b2 b1 | Meaning O O O O O O O O --No informatlon IS 91Ven O - - - - - - - --Global reference data (e.g., an MF speafic key~ ---------Specific reference data (e.g.. a DF speclfic key) -x x - - - - - 00 iother values are RFU) ---x x x x x --Number of the secret NOTES
The number of the secret may be for example a key number or a short EF idemlfier.
2 When the body is emptv, the command may be used elther to retneve the number X of further allowed retries (SWI SW2 = 63CX ) or to check whether the verification IS not re~ulred (SW1-SW2 = 9000 ).
6.14.4 Response messa~e (nominal case~ Table 69 -- EXTERNAL AUTHENTICATE response APDU Data field Empty SW1-SW2 Status bvtes 6.14.5 Status conditions
The following specific warning conditions may occur.
--SW1 = '63' with SW2 =
ù '00': No information given (authentication failed).
ù 'CX': Counter (authentication failed; 'X' indicates the number of further allowed retries).
~iSOiiEC
The following specific error conditions may occur.
--SW1 = '67' with SW2 =
ù '00': Wrong length (the L field is incorrect).
--SW1 = '69' with SW2 =
ù '83': Authentication method blocked.
ù '84': Referenced data invalidated.
ù '85': Conditions of use not satisfied (the command is not allowed in the context).
--SW1 = '6A' with SW2 =
ù '86': Incorrect parameters P1-P2
ù'88': Referenced data not found.
6,15 GET CHALLENGE command 6,15.1 Definition and scope
The GET CHALLENGE command requires the issuing of a challenge (e.g, random number) for use in a security related procedure (e.g., EXTERNAL AUTHENTlCATE command).
6.15.2 Conditional usage and security
The challenge is valid at least for the next command. No further condition is specified in this part of ISO/IEC 7816.
6.15.3 Command message Table 70 --GET CHALLENGE command APDU
CLA As deflned In 5 4 1 I NS ' 84 ' P1-P2 '0000' (other values are RFU~ Lc field Empty Data fleld Empty
Le 'ield Maxlmum length of the expected response 6.15.4 Response message ~nominal case~ Table 71 -- GET CHALLENGE respons~ APDU Data field SW1 -SW2 Challenge Status bvtes fi l5 5 Status conditions
The following specific error conditions may occur.
--SW1 = '6A' with SW2 =
ù '81': Function not supported.
ù '86': Incorrect Darameters P1-P2.
6.16 MANAGE CHANNEL command 6.16.1 Definition and scope
The MANAGE CHANNEL command opens and closes logical channels .
The open function opens a new logical channel other than the basic one. Options are provided for the card to assign a logical channel number, or for the logical channel number to be supplied to the card.
The close function explicitly closes a logical channel other than the basic one. After the successful closing, the logical channel shall be available for re-llse
6.16.2 Conditional usage and security
When the open function is performed from the basic logical channel, then after a successful open. the MF shall be implicitly selected as the current DF and the security status for the new logical channel should be the same as for the basic logical channel after ATR. The security status of the new logical channel should be separate from that of any other loqical channel.
When the open function is performed from a logical channel which is not the basic one, then after a successful open, the current DF of the logical channel from whlch the command was issued shall be selected as the current DF and the security status for the new logical channel should be the same as for the logical channel from which the open function was performed.
After a successful close funct~on, the security status related to this logical channel is lost.
6.16.3 Command message
l'abl~ 72 -- MANAGE CHANNEL command APDU
CLA As deflned Ir 5 4 1 I NS ' 70 Pl P1 = 00' to open a logical channel P1 = '80' to close a logical channel (other values are RFU) P2 '00', '01', '02' or '03' (other values are RFU) Lc field Empty
Data field Empty Le field '01' if P1-P2 = '0000' Empty If P1-P2 . '0000'
Bit b8 of P1 is used to indicate the open function or the close function; if b8 is 0 then MANAGE CHANNEL shall open a logical channel and if b8 is 1 then MANAGE CHANNEL shall close a logical channel
!~' /0 !0 ~ C:
For the open function (P1 = '00'), the bits bl and b2 of P2 are used to code the logical channel number in the same manner as in the class byte (see 5.4.1); the other bits of P2 are RFU.
--When bl and b2 of P2 are null, then the card will assign a logical channel number that will be returned in bits bl and b2 of the data field.
--When bl and/or b2 of P2 are not null, they code a logical channel number other than the basic one; then the card will open the externally assigned logical channel number.
6.16.4 Response message (nominal case)
Table 73--MANAGE CHANNEL response APDU
Data field SW1 -SW2
Logical channel number If P1-P2 = '0000' Empty if P1-P2 . '0000'
Status bytes
6.16.5 Status conditions
The following specific warning conditions may occur.
--SW1 = '62' with SW2 =
ù '00' No information is alven
7 Transmission-oriented interindustry commands
It shall not be mandatory for all cards complying to this part of ISO/IEC 7816 to support all the described commands or all the options of a supported command.
When international interchange is required. a set of card system services and related commands and options shall be used as defined in clause 9
Table 11 provides a summary of the commands defined in this part of ISO/IEC 7816.
The impact of secure messaging (see 5.6) on the message structure is not described in this clause.
The list of error and warning conditions given in each clause 7.X.5 is not exhaustive (see 5.4.5).
29
ISO/IEC 781~4:1995 (E~ 7.1 GET RESPONSE command 7.1.1 Definition and scope
The GET RESPONSE command is used to transmit from the card to the interface device APDU(s) (or part of APDUs) which otherwise could not be transmitted by the available protocols.
7,1.2 Conditional usage and security
No condition.
7.1.3 Command message Table 74-- GET RESPONSE command APDU
CLA As defined in 5.41 I NS ' C0' P1-P2 '0000' (other values are RFU) Lc field Empty Data field Empty Le field Maxlmum length of data expected in response
7.1.4 Response message (nominal case~
If the Le field contains only ~eroes, then within the limit of 256 for short length or 65 536 for extended length, all the available bytes should be returned.
Table 75-- GET RESPONSE reSDOnse APDU
Data fleld (Pan of) APDU accoralng to Le SW1-SW2 Status bvtes
7.1.5 Status conditinn~
The following specific normal processing may occur.
--SW1 = '61 ' with SW2 =
ù 'XX': Normal processing : more data bytes are
available ('XX' indicates a number of extra data bytes
still available by a subsequent GET RESPONSE).
The following specific warning condition may occur --SW1 = '62' with SW2 =
ù'81': Part of returned data may be corrupted.
The following specific error conditions may occur.
--SW1 = '67' with SW2 =
ù'00': Wrong length (incorrect Le field).
--SW1 = '6A' with SW2 =
ù'86': Incorrect parameters P1-P2.
3 D
o ISO/itC
--SW1 = '6C' with SW2 =
ù 'XX': Wrong length (wrong Le field: 'XX' indicates the
exact length).
7 .2 ENVELOPE command 7.2.1 Definition and scope
The ENVELOPE command is used to transmit APDU(s), or part of APDUs, or any data string, which otherwise could not be transmitted by the available protocols.
NOTE--The usage of ENVELOPE for SM is shown in annex F 7.2.2 Conditional usage and securit-~
No condition.
7.2.3 Command message Table 76--ENVELOPE command APDU CLA As defined In 5.4.1
INS 'C2'
P1-P2 '0000' (other values are RFU)
Lc field Length of the subsequent data field Data field (Part of) APDU
Le field Empty or length of expected data
When the ENVELOPE command is used under T=0 for transmitting data strings, an empty data field in an ENVELOPE command APDU means "end of data string-.
7.2.4 Response messa~e ~nominal casol Table 77 -- ENVELOPE response APDU Data field SW1 -SW2 Empty ompart of) APDU according to Le Status bvtes
NOTE--The status bytes Delong to the ENVELOPE command. Status bytes of a commanr~ uansmltted In the data field of the ENVELOPE command may ~e found In the data field of the ENVELOPE response.
7.2.5 Status conditions
The following specific error condition may occur.
--SW1 = '67' with SW2 =
ù lool
Wrong length (incorrect Lc field).
8 Historical b~rtes
8.1 Purpose and general structure
The historical bytes tell the outside world how to use the card when the transport protocol is ascertained according to part 3 of ISO/IEC 7816.
The number of historical bytes (at most 15 bytes) is specified and coded as defined in Dart 3 of ISO/IEC 781~
The information carried by the historical bytes may also be found in an ATR file (default EF identifier = '2F01')
If present, the historical bytes are made up of three fields:
--a mandatory category indicator (1 byte), --optional COMPACT-TLV data objects,
--a conditional status indicator (3 bytes).
8.2 Categor~ indicator (mandator~)
The category indicator IS the first historical byte. If the category indicator is equal to '00', '10' or '8X', then the format of the historical bytes shall be according to thls part of ISO/IEC 7816.
Table 78--Coding of the category indicator
Value Meaning 00 Status Informatlon shall be present at the end of the hlstoncal bytes ~not In TLV) '10' 8peclfled In 8.5 '80' Status Informatlon, if present, IS contained in an optlonal COMPACT-TLV data oblect '81' to '8F' RFU Other values Propnetary
8.3 Optional COMPACT-TLV data objects
The coding of the COMPACT-TLV data objects is deduced from the basic encoding rules of ASN.1 (see ISO/IEC 8825 and annex D) for EER-TLV data objects with tag = '4X' and length = '0Y'. The coding of such data objects is replaced by 'XY' followed by 'Y' bytes of data. In this clause, 'X' is referred to as the tag number and 'Y' as the length.
Besides the data objects defined in this clause, the historical bytes may contain data objects defined in part 5 of ISO/IEC 7816. In this case, the coding of the tags and length fields defined in part 5 shall be modified as above.
When COMPACT-TLV data objects defined in this clause appear in the ATR file, they shall be encoded according to the basic encoding rules of ASN.1 (i.e.. tag = '4X', length = 'OY').
All application-class tags not defined in ISO/IEC 7816 are reserved for ISO.
8.3.1 Country/issuer indicator
When present, this data object denotes a country or an issuer.
This data object is introduced by either '1Y' or '2Y' Table 79--Coding of the country/issuer indicator Tag Length Value '1~ variable Country code and natlonal data '2' variable Issuer identificatlon number
The tag '1' is followed by the appropriate length (1 nibble) and by three digits denoting the country as defined in ISO 3166. Data which follows (odd number of nibbles) is chosen by the relevant national standardization body.
The tag '2' is followed by the appropriate length (1 nibble) and by the issuer identification number as defined in part 1 of ISO/IEC 7812. If the issuer identification number contains an odd number of digits, then it shall be right padded with a nibble valued to 'F'.
8.3.2 Card service data
This data object denotes the methods available in the card for supporting the services described in ciause 9.
This data object is introduced by '31'
When this data object is not present, the card supports only the Implicit application selection
Table 80--Card-profile for application-independent card services
. ~
b8 b7 b6 b5 b4 b3 b2 bl Meaning
Direct appilcation selectlon by full DF name
-1 - - - - - --Selectlon bv partial DF name
(see 9.3.2) Data objects available
---In DIR file
--in ATR file File IIO services by ----1 - - - --READ 31NARY command ----O - - - --READ RECORD(S) command
.
-----x x x 000 (other vaiues are RFUI
NOTE--The contents of the DIR and ATR files may give Information on selectlon methods.
8.3.3 Initial access data
This optional data object allows the retrieval of a string of data objects defined in ISO/IEC 7816. The string retrieved by this data object is called the ùinitial data string-.
This data object is introduced by '41', '42' or '45'.
ISO/IEC 781~4:1995 (E~
Any command APDU described in this clause is assumed to be the first command sent after the answer to reset. Consequently, the data available at this point may not be subsequently retrievable.
8.3.3.1 Length ='1'
When oniy one byte of information is provided, it indicates the length of the command to perform for retrieving the initial data string. The command to perform is a READ BINARY command structured as follows.
Table 81--Coding of the command when len~th = '1'
CLA '00' (see 5.4.1) I NS ' B0' p1 -P2 'øøøø'
Lc field Empty Data field Empty
Le field First and only byte of value field of initlal access data (indlcating the number of bytes to be read)
8.3.3.2 Length = '2'
When two bytes of informatlon are provided, the first bvte indicates the file structure (transparent or record) and the short identifier of the EF to be read. The second bvte indicates the length of the READ command to perform for retrievinq the initial data strinq.
Table 82--Structure of the first byte
= o Record onented file = 1 Transparent file oo (other values are RFU)
b 7-b6 b5-bl I Short EE identifier
ù When b8=0, the command to perform is READ RECORD(S) command structured as follows.
Table 83--Codin~ of the command when b8=0
CLA '00' (see 541) NS ~B2 ' Pl '01 P2 Short EF idennfier (from the flrst byte of Initlal access data) followed by b3-b2-bl = 110
Lc field Empty Data field Empty
Le field Second and last byte of value field of Inltial access| data (indicating the number of bytes to be read)
ù When b8=1, the command to perform is a READ BINARY command structured as follows.
Tablo 84--Coding of the command when b8=1 CLA 00' (see 5.4.1) NS ' B0 ' Pl Value of the first byte of initial access data P2 'øø'
Lc field Empty Data field Empty
Le field Second and last byte of value field of initial access
~ISO/IEC 8.3.3.3 Length = '5'
The value found in the initial access data object consists of the APDU of a command to perform. When executed, this command provides the initial data string in its response data field.
8.3,4 Card issuer's data
This data object is optional and of variable length. Structure and coding are defined by the card issuer.
This data object is introduced by '5Y'.
8,3.5 Pre-issuin~ data
This data object is optional and of variable length Structure and coding are not defined in this part of ISO/IEC 7816. It may be used for indicating
--card manufacturer, --integrated circuit type,
--integrated circuit manufacturer.
--ROM mask version,
--operating system version.
This data object is introduced by '6Y'.
8.3.6 Card capabilities
This data object is optional and of variable length. Its value field consists of either the first software function table, or the first two software function tables, or the three software function tables.
This data object is introduced by '71', '72' or '73'.
Table 85 shows the first software function table.
Table 85--First software function table b8 b7 b6 b5 b4 b3 b2 bl
Meaning DF selection --by full DF name --by panlal DF name --by Path --by file identifier --implicit EF management --Shon EF identifier supported --Record number supported --Record Identifier supported
Table 86 shows the second software function table which is the data coding byte. The data coding byte may also be present as the second data element in the file control parameter with tag '82' (see table 2 in 5.1.5).
Table 86--Second software function table (data coding byte) b8 b7 b6 b5 b4 b3 b2 b1 Meaning -x x - - - - - Behavior of write functions -o O - - - - - --one-time write -O 1 - - - - - --propnetary 0 - - - - - --wnte OR -------write AND -----x x x Data unit size in nibbles (power ot 2. e.g., 001 = 2 nlbbles)
(default value = one bvte) x - - x x - - - O. .00.. (other va(ues are RFU)
Table 87 shows the third software function table Table 87--Third software function table
b8 b7 b6 b5 b4 b3 b2 bl Meaning x - - - - - - O (1 IS RFU) -1 - - - - - --Extended Lc and Le fields --X - - - - - O (1 IS RFU) ---x x - - - Logical channel assignment --by the card --by the Interface devlce ---O O - - - No loglcal channel -----x - - O (1 is RFU) ------x y --Maximum number of loglcal channeis (= 2x+~+Ii
8.4 Status inforrnation
The status information consists of 3 bytes: the card life status (1 byte) and the two status bytes SW1-SW2.
The value '00' of the card life status indicates that no card life status is provided. The values '80' to 'FE' are DropnetarV All other values are RFU
The value '9000' of SW1-SW2 indicates normal processing as defined in 5.4.5.
The value '0000' of SW1-SW2 indicates that the status is not indicated.
If the category indicator is valued to '80', then the status information may be present in a COMPACT-TLV data object. In this case, the tag number is '8'. When the length is '1', then the value is the card life status. When the length is '2', then the value is SW1-SW2. When the length is '3', then the value is the card life status followed by SW1SW2. Other values of the length are reserved for ISO.
8.5 DIR data reference
If the category indicator is '10', then the following byte is the DIR data reference. The coding and meaning of this byte are outside the scope of this part of ISO/IEC 7816.
Application-independent card services
9.1 Definitions and scope
This clause describes the application-independent card services, referred to as ~card services" in the following text. Their purpose is to provide interchange mechanisms between a card and an interface device knowing nothing about each other except that they both comply with this part of ISO/IEC 7816.
Card services are supported by any combination of
--historical bytes, --contents of one or more reserved EFs,
--sequences of interindustry commands.
The commands use CLA = 00' (see 5 41), i.e., no secure messaging and the basic loglcal channei.
There is no need for an application to comply with this clause once it has been identified and selected in the card. It is possible for an applicatlon to use other mechanisms compatible with this part of ISO/IEC 7816 for achieving similar functions. Therefore such solutions may not guarantee interchange.
The following card services are defined.
--Card identification servlce--This service allows the interface device to identify the card as well as how to deal with it
--Application selectlon servlce--Thls service allows the interface device to know what application is active in the card (if any) as well as how to select and start an application in the card.
--Data object retrieval service--This service allows to retrieve data objects defined either In this part or in other parts of ISO/IEC 7816. This clause describes standard mechanisms only for interindustry data objects.
--File selectlon service--This service allows selection of un-named DFs, and EFs.
--File l/O service--This service allows access to data ~tore~l in EF~
9.2 Card identification service
This function consists of the card providing information to the outside world on its logical content as well as some general data objects all applications might be interested in (e.g., interindustry data objects). The information, called ~card identification data~, is given by the card in the historical bytes and possibly in a file implicitly selected immediately after the answer to reset.
Access to this file is indicated in the initial access data information (see 8.3.3).
33
ISO/IEC 781~4:1995 ~E~
If the initial access data of the historical bytes does not denote a READ command, then the response to the command to perform contalns card identification data.
9.3 Application selection service
An application is either implicitly selected in a card or can be explicitly selected by its name.
9.3.1 Implicit application selection
When an application is implicitly selected in a card, the application identifier as defined in part 5 of ISO/IEC 7816 should be indicated in the card identification data. If not present in the card identification data, then it shall be present in the ATR file.
9.3.2 Direct application selection
A card in a multi-application environment shall be able to respond positively to a direct applicatlon selection performed by a SELECT FILE command specifying the application identifier as DF name.
The application identifier should be provided completely in the command APDU. In case of an applicatlon selection by partial DF name, the next application matching with the name proposed may be selected and the full DF name will be made available in the response message of the SELECT FILE command as the file control parameter with tag '84' (see table 2 in 5.1.5).
The APDU of the command to perform is the following.
Table 88--Coding of the command for direct application selection CLA '00' (see 5.41) INS 'A4 ' P1 -P2 '0400'
Lc field Length in bytes the data fleld Data field Full or partla: DF name Le field Present, contalns only zeroes
9.4 Data object retrieval service
Data objects used for application-independent international interchange are defined in this part and other parts of ISO/IEC 7816.
The retrieval of those data objects relies on one or both of the following methods:
--presence of a data object in the card identification data (see 9.2),
--presence of a data object in the DIR file (path = '3F002F00') or in the ATR file (path = '3F002F01').
The information necessary to retrieve data objects by an indirect method are defined in part 6 of ISO/IEC 7816.
~U/IC1
9.5 hle selection service
When the path to an EF is known, the number of SELECT FILE commands to be Issued equals the length of the path divided by two, minus one (the path always starts with the current DF).
If the path length is more than four bytes, then until all available DF Identifiers of the path have been used, one or more SELECT FILE commands shall be performed with the following command APDU
Table 89--Coding of tne commana to select a u~ using a file identifier
CLA '00' (see 5.4.1) INS 'A4 '
P1-P2 '01 00'
Lc field '02'
Data field DF identifier (from bytes 3 and 4 of the path)
Le field Empty
The last and possibly only selection IS an EF selection with the followina command APDU.
Table 90--Coding of the command to select an EF
CLA '00' (see 5.41) INS 'A4' P1 -P2 '0200'
Lc field '02'
Data field EF idennfier (last two bytes of the path
Le field Empty
9.6 File l/O service
Once a file used for interindustry interchange has been selected, the contents relevant to interchange shall be returned by one of the following command APDUs.
ù If the first software function table is absent, or does not denote the support of record-oriented commands, then the following command shall be performed.
Table 91--Coding of the command to read
a transparent file C LA ' 00 ' (see 5 4 1 ) INS ' B0 ' P1 -P2 ' 0000 ' Lc field Empty
Data field Empty
Le field Present, contalns only zeroes
ù If the first software function table denotes the support of record-oriented commands, then the followlng command shall be performed.
Table 92--Coding of a command to read
a rocord-orionted filo CLA '00' (see 5.41) INS ' E; 2 ' P1 -P2 '0005' Lc field Empty
Data field Empty
Le field Present, contains only zeroes
Annex A (normative) Transportation of APDU messages by T=O A.1 Case 1
The command APDU is mapped onto the T=O command TPDU by assigning the value '00' to P3.
Command APDU (~nmm~nrl TPn~J CLA INS P1 P2
The response TPDU is mapped onto the response APDU without anv chanae.
Response TPDU Response APDU I SWl SW2 A.2 Case 2 Short
In this case, Le IS valued from 1 to 256 and coded on byte B 1 (B1 = '00' means maximum, i.e., L,, = 256).
The command APDU is mapped onto the T=O command TPDU without any change.
C-APDU C-TPDU CLA INS Pl P2 | Le = CLA INS P1 P2 | P3 = B ll
The response TPDU is mapped onto the response APDU according to the acceptance of Le and according to the processing of the command.
Case 2S.1--Le accepted
The response TPDU is mapped onto the response APDU without anv chanqe.
R -TPD U R-APD U
Le bytes T swl SW2 | Le bytes | SW1 SW2 |
Case 25.2--Le definitely not accepted
Le is not accepted by the car'd which does not support the service of providing data if the length IS wrong.
The response TPDU from the card indicates that the card aborts the command because of wrong length: (SW1) = '67' The response TPDU is mapped onto the response APDU without any change.
R-TPDU | SWl= 67 SW2 | R-APDU | SWl = 67 SW2 | Case 2S.3--Le not accepted, La indicated
Le is not accepted by the card and the card indicates the available length LA
The response TPDU from the card indicates that the command is aborted due to a wrong length and that the right length is LA . (SW1 ) = '6C' and SW2 codes La.
If the transmission system does not support the service of re-lssuing the same command, it shall map the response TPDU onto the response APDU without any chanqe .
R-TPDU | SWl = ~6C~ SW2 = La | R-APDU I SWl = 6C SW2- Lal
If the transmission system supports the service of reissuing the same command, it shall re-issue the same command TPDU assigning the value La to parameter P3.
;~UIIt~ ~4:1YY5 ~t) ~) !SO!!E'
C-TPDU CLA INS Pl P2 P3 = SW2
The response TPDU consists of La bytes followed by two status bvtes.
If La is smaller than or equal to Le~ then the response TPDU is mapped onto the response APDU without any change.
R-TPD U R-APDU La bytes | SWl SW2 La bytes | SWl SW2
If La is greater than Le~ then the response TPDU is mapped onto the response APDU by keeping only the first Le bytes of the body and the status bytes SW1-SW2
R-TPnl I R-APnl I La bytes SWl SW2 Le (< Lal bytes | SWl SW2 Case 2S.4--SW1-SW2 = '9XYZ', except '9000'
The response TPDU is mapped onto the response APDU without any change.
A.3 Case 3 Short
In this case, Lc is valued from 1 to 255 and coded on byte B~ (~'00').
The command APDU is mapped onto the T=O command TPDU w~thout any change.
~-Apnl l C-TPDU CLA INS Pl P2 | Lc = Bl | Lc bYtes ~~P3 - B l | Lc bvtes
The response TPDU is mapped onto the response APDU without any change.
R-TPD U R-APDU I SWl SW2 A.4 Case 4 Short
In this case. Lc is valued from 1 to 255 and coded on byte B1, Le is valued from 1 to 256 and coded on bvte BL (BL = '00' means maximum i.e., Le = 256).
The command APDU is mapped onto the T=O command TPDU by cutting off the last byte of the body.
~-Apnl l C-TPDU CLA INS P1 P2 | Bl = -c | Lc bvtes | BL CLA INS Pl P2 IP.~ = F.~ I I h\/ta~ Case 4S.1--Command not accepted
The first response TPDU from the card indicates that th~ card aborted the command: SW1 = '6X', except '61'
The response TPDU is mapped onto the response APDU without any chanqe.
R-TPDU R-APDU SW1='6X' SW2 SWl= 6X SW2 Case 45.2--Command accepted
The first response TPDU from the card indicates that the card performed the command: SW1-SW2 = '9000'.
The transmission system shall issue a GET RESPONSE command TPDU to the card by asslgnlng the value Le to parameter P3.
C-TPDU CLA INS = GET RESPONSE Pl P2 P3 = B L
Depending on the second response TPDU from the card. the transmission system shall reacl as described in cases 2S.1. 2S.2. 2S.3 and 2S 4 ~h~vP
Case 4S.3--Command accepted with information added
The first response TPDU from the card indicates that the card performed the command and gives information on the length of data bytes available: SW1 = '61' and SW2 codes Lx
The transmission system shall issue a GET RESPONSE command TPDU to the card by asslgnlng the minimum of Lx and Le to parameter P3.
TPD U CLA INS = GET RESPONSE Pl P2 | P3 = rnln IL,.. Ly)
The second response TPDU is mapped onto the response APDU without any change.
R-TPDU R-APDU
P3 bytes | SWl SW2 P3 bytes | SWl SW2
Case 4S.4--SW1-SW2 = '9XYZ', except '9000'
The response TPDU is mapped onto the response APDU without any change.
A.5 Case 2 Extended
In this case, Le is valued from 1 to 65 536 and coded on 3 bytes: (B1) = 'øø', (B2 ll B3) = any value (B2 and B3 valued to '0000' means maximum. i.e., L~ = 65 536).
C-APDU CLA INS Pl P2 | Bl = 00 B2 B3 = Le
Case 2E.1--Le ~ 256, B1 = '00, B2 B3 from '0001' to '0100'.
The command APDU shall be mapped onto the command TPDU by assigning the value of B3 to parameter P3. The processing by the transmission system shall be according 1t~ r~ce
C TPDU CLA INS Pl P2 P3 = B3
Case 2E.2--Le > 256, B1 = '00, B2 B3 = either '0000' or from '0101' to 'FFFF'
The command APDU shall be mapped onto the command TPDU by assigning the value of '00' to parameter P3.
C TPDU CLA INS Pl P2 | P3 = '00
a) If the first response TPDU from the card indicates that the card aborted the command because of wrong length (SW1 = '67'), then the response TPDU shall be mapped onto the response APDU without any change.
R TPDU | SW1 = 67 SW2 R APDU | SW1 = 67 SW2
b) If the first response TPDU from the card indicates that the command is aborted due to a wrong length and that the right length is La (SW1 = '6C' and SW2 = La), then the transmission system shall complete the processing as described in case 2S.3.
c) If the first response TPDU jS 256 bytes of data followed by SW1-SW2 = '9000', this means that the card has no more than 256 bytes of data, and/or does not support the GET RESPONSE command. The transmission system shall then map the response TPDU onto the response APDU without anv chanqe.
R-TPn l J R-APDU l 256 bytes | SWl = 90' SW2 = 00' L 256 bytes | SWl = 90 SW2 = øø' l
d) If the first or subsequent response TPDU from the card is SW1 = '61', then SW2 codes Lx which is the extra amount of bytes available from the card (SW2 valued to '00' indicates 256 extra bytes or more), the transmission system shall compute Lm = Le - (sum of the lengths of the bodies of the previously received response TPDU(S)) to obtain the amount of remaining bytes to be retrieved from the card.
If Lm = O. then the transmission system shall concatenate the bodies of all received response TPDUS together with the trailer of the last received response TPDU into the response APDU.
If Lm > O, then the transmission system shall issue a GET RESPONSE command TPDU by asslgnlng the minimum
of Lx and Lm to parameter P3. The corresponding response TPDU from the card shall be processed
--according to case d), if SW1 = '61'.
--as above when Lm = O. if SW1 = '90'.
A.6 Case 3 Extended
In this case, Lc is valued from 1 to 65 535 and coded on 3 bytes: (B1) = '00', (B2 ll B3) ~'00 00'.
C APDU CLA INS Pl P2| Bl = 00 B2 B3 = Lc | Lc bytes Case 3E.1--ø ~ Lc < 256, B1 = '00', B2 = '00', B3 ~ '00'
The command APDU jS mapped onto the command TPDU by assigning the value of B3 lo parameter P3.
C TPDU CLA INS Pl P2 P3 = B3 Lc bytes
In this case, Lc is valued from 1 to 255 and coded on 1 byte.
The response TPDU jS mapped onto the response APDU without any change.
R-TPDU R-APDU SWl SW2 I SWl SW2 1 Case 3E.2--Lc > 255, B1 = 'øø', B2 ~ '00', B3 = any value
If the transmission system does not support the ENVELOPE command, it shall return an error response APDU meaning that the length is wrong: SW1 = '67'.
R-TPDU | SWl= 67 SW2 R-APDU | SWl= 67' SW2 l
If the transmission system suppol-ts the ENVELOPE command, it shall split the APDU into segments of length less than 256, and send those successive segments into the bodies of consecutive ENVELOPE command TPDUS.
C-TPDU CLA INS = ENVELOPE P1 P2 | P3 | P3 bytes
l~iU/lt~ 7816-4: 1995 (E) ~ !SO/!EC
If the first response TPDU from the card indicates that the card does not support the ENVELOPE command (SW1 = '6D'), the TPDU shall be mapped onto the response TPDU without any chanqe.
R-TPDU R-APDU SW1 ='6D' SW2 SW1 ='6D' SW2 |
It the first response TPDU from the card indicates that the card does support the ENVELOPE command (SW1-SW2 = '9000'), the transmission system shall send further ENVELOPE commands as needed.
Case 4E.1--Lc < 256, B 1 = 'øø, B2 = 'øø'- B3 ' 'øø'
The command APDU is mapped onto the command TPDU by cutting off the last two bytes BL-1 and BL and by assigning the value of B3 to parameter P3.
C-TPDU CLA INS Pl P2 | P3 = a3 A.7 Case 4 Extended
In this case. Lc is valued from 1 to 65 535 and coded on 3 bytes: (B,) = 'øø' (B2 ll B3) '0000' and Lo 15 valued from 1 to 65 536 and coded on 2 bytes: (BL-1 ll BL) = any value (BL-1 and BL valued to '0000' means maximum, i e . Le = 65 536).
Lc bytes
In this case, Lc is valued from 1 to 255 bytes and coded on 1 bvte.
a) If SW1 = '6X' in the first response TPDU from the card. then the response TPDU is mapped onto the response APDU without anv chance.
SWl-SW2= gooo | | SW1 = 6x Sw2 |
C-TPDU CLA INS = ENVELOPE P1 P2 P~ bvtes
The response TPDU corresponding to the last ENVELOPE command is mapped onto the response APDU without any change.
R-TPD U R-APD LJ SW1 SW2 C-APDU CLA INS Pl P2|Bl = 00' B7B~ = L~ 38 Lc bytes BL_1 aL = Le R-APDU | Sw1 = 6x SW2 |
b) If SW1 = '90' in the first response TPDU from the card, then
If Le < 257 (BL-1 BL valued from '0001' to '0100'), then the transmission system shall issue a GET RESPONSE command TPDU by assigning the value Of BL to parameter P3. The subsequent processing by the transmission system shall be according to cases 2S.1, 2S.2, 2S.3 and 2S.4 a bove .
If Le > 256 (BL-1 BL valued to '0000' or more than '0100'), then the transmission system shall issue a GET RESPONSE command TPDU by assigning the value '00' to parameter P3. The subsequent processing by the transmission system shall be according to case 2E.2 above.
c) If SW1 = '61' in the first response TPDU from the card, then the transmlssion system shall proceed as specified in case 2E.2 d) above.
Case 4E.2--LC ~ 255, B1 = 'øø. B2 ~100'. B3 = any value
The transmission system shall go on according to case 3E.2 described above. until the command APDU has been sent completely to the card. It shall then go on as described in case 4E.1 a), b) and c) descnbed above.
Annex B (normative) Transportation of APDU messages by T=1 B.l Case1
The command APDU is mapped onto the information fleld of an l-block wlthout any change
Information field | CLA INS Pl P2
The information field of the l-block received in response is mapped onto the response APDU without any chanqe.
Information field Response APDU | SWl SW2 | B.2 Case2(sho~ande~ended) or concatenation of information fields R-APnl J Data fleld SWl -SW2 SW1 -SW2 B.3 Case3~sho~ ande~ended)
The command APDU is mapped without any change onto --either the information field of one l-block --or the concatenation of the information fields of successive l-blocks whlch shall be chalned.
C-APDU CLA INS Pl P2 I Lc field I Data field C-APDU Informa~ion fielrl
CLA INS Pl P2 | Le field | CLA INS Pl P2 | Le fleld |
The response APDU consists of --either the information field of the l-block received in response.
Either information field The command APDU IS mapped onto the Informatlon fleld of an l-block wlthout any change.
CLA INS Pl P2 I Lc fleld I Data field
or concatenation of information fields
CLA INS P1 P2 | Lc fleld | Data ...
field The information field of the l-block recelved in response is
--or the concatenation of the information fields of mapped onto the response APDU without any change. successive l-blocks received in response. These blocks shall be chained.
Either information field Data field Information field SWl-SW2 I R-APDU I SWl SW2 1
:1sss!E! Q!SO/!EC B.4 Case 4 (short and extended) The response APDU consists of
The command APDU is mapped without any change onto --either the information field of one l-block,
--or the concatenation of the information fields of cllcrf~cciv~ hlorkc whirh chall h~ nhain~rl
C-APDU CLA INS P1 P2 Lc fleld Data field Lefield ~rmation field CLA INS P1 P2 Lc fleld Data fleld Lefleld Either information field or concatenation of information fields CLA INS P1 P2 |LC fleld| Data
fleld | Le fleld
--either the information field of the l-block received In response,
--or the concatenation of the information fields of successive l-blocks received in response. These blocks shall be chained.
Either information field Data fleld or concatenation of infnrmation fi~ c R-APD U Data fleld SW1 -SW2 SW1 -SW2 SW1 -SW2
Anne (inform Record pointer C. 1 Case 1
Case 1 deals with the first command issued after a select function (either explicit or implicit). The current record pointer (CP) is undefined.
Command RF~ RFl't'lRr~C Record in res~onse Positlon of CP ~ft~r rrlmm~n~l
Next (id=aa) First with id=aa Record read If not found, then error Undefined Previous (id=bb) Last with id=bb Record read If not found, then error Undefined First (id=cc) First with id=cc Record read
If not found, then error Undefined
Last (id=dd) Last with id=dd Record read
If not found, then error Undefined
Next (id=OO) First Record read Previous (id=OO) Las~ Record read
First (id=OO)
Last (id=OO)
Record # 00
Record # ee
First Last
Record read Record read
Error Undefined # ee U ndefined If not found. then error Undefined P1='OO', P2=xxxx x101 Error Undefined P1='OO', P2=xxxx x110 Error Undefined # jj, P2=xxxx x101 # jj to last Undefined
If # jj not found, then error Undefined # kk, P2=xxxx x110 Last to # kk ... If # kk not found. then error Undefined Undefined
!X C ative) management C.2 Case 2 (~ø 1~
Case 2 deals with a subsequent command. The current record pointer (CP) is defined.
Command READ RECORDS
Record in response
Next (id=aa) Next with id=aa
If no next, then error Previous (id=bb) Previous with id=bb
If no previous, then error First (id=cc) First with id=cc If not found, then error Last (id=dd) Last with id=dd If not fo~lnr~ then error Next (id=OO) CP+l If CP = last, then error
Previous (id=OO) CP-1
If CP = first, then error First (id=OO) First Last (id=OO) Last
Record # 00 Record # ee Position of CP after command Record read Unchanged
Record read U nchanged
Record read U ncha nged
Record read Unchanged
Previous CP+1 Unchanged
Previous CP-1 Unchanged
First record Last record
CP Unchanged # ee U nchanged If not found, then error Unchanged P1='OO', P2=xxxx x101 CP to last Unchanged
P1='OO', P2=xxxx x110 Last to CP Unchanged # jj, P2=xxxx x101 # jj to last If # jj not found, then error
Unchanged Unchanged
Unchanged # jj, P2=xxxx x1 1 0 Last to # kk If # kk not found, then erroruncnangec
~SO/IEC 781~4:1995 (E)
Ann~ (inforrr Use of the basic enc~
D. 1 BER-TLV data object
Each BER-TLV data object (see ISO/IEC 8825~ shall consist of 2 or 3 consecutive fields.
--The tag field T consists of one or more consecutive bytes. It encodes a class, a type and a number.
--The length field consists of one or more consecutive bytes. It encodes an integer L
--If L is not null, then the value field V consists of L consecutive bytes. If L is null, then the data object IS empty: there is no value field.
ISO/IEC 7816 uses neither '00' nor 'FF' as tag value
NOTE--Before, between or after 3ER-TLV data objects, oo or 'FF' bytes wlthout any meanlng may occur (e g, due to erased or modified TLV coded data objects).
D.2 Tag field
The bits b8 and b7 of the leading byte of the tag field shall encode the tag class, i e., the class of the data object.
--b8-b7=00 introduces a tag of universal class.
--b8-b7=01 introduces a tag of application class.
--b8-b7=10 introduces a tag of context-specific class.
--b8-b7=11 introduces a tag of private class.
The bit b6 of the leading byte of the tag field shall encode the tag type, i e., the type of the data object.
--b6=0 introduces a primitive data object.
--b6=1 introduces a constructed data object
If the bits b5 to bl of the leading byte are not all set to 1, then they shall encode an integer equal to the tag number which therefore lies in the range from 0 to 30. Then the tag field consists of a single byte.
Otherv~ise ~b5 to bl set to 1 in the leading byte), the tag field shall continue on one or more subsequent bytes
~ISO/IEC
~x D ative) ding rules of ASN.1
--The bit b8 of each subsequent byte shall be set to 1, unless it is the last subsequent byte.
--The bits b7 to bl of the first subsequent byte shall not be all set to 0.
--The bits b7 to bl of the first subsequent byte, followed by the bits b7 to bl of each further subsequent byte, up to and including the bits b7 to bl of the last subsequent byte, shall encode an Integer equal to the taa number (thus strictlv Dositive).
D.3 Length field
In short form, the length field consists of a single byte where the bit b8 shall be set to 0 and the bits b7 to bl shall encode an integer equal to the number of bytes in the value field. Any length from 0 to 127 can thus be encoded by 1 byte.
In long form, the length fieid consists of a leading byte where the bit b8 shall be set to 1 and the bits b7 to bl shall not be all equal, thus encoding a posltlve integer equal to the number of subsequent bytes In the length field. Those subsequent bytes shall encode an Integer equal to the number of bytes in the value field. Any length within the APDU limit (up to 65 535) can thus be encoded bv 3 bytes.
NOTE--ISO/IEC 7816 does not use the Indefinite lengths specified by the baslc encoding rules of ASN. 1 (see ISO/IEC 8825) .
D.4 Valuefield
In this part of ISO/IEC 7816, the value field of some primitive BER-TLV data objects consists of zero, one or more SIMPLE-TLV data objects.
The value field of any other primitive BER-TLV data object consists of zero, one or more data elements fixed by the sDecifications of the data obiect.
The value field of each constructed BER-TLV data object consists of zero, one or more BER-TLV data obiects.
Ann~ (inform Examples of E. 1 Introduction
This annex defines a number of card profiles to guide application designers in selecting commands to use in their applications. The profiles may also be used to help specify the features desired in a card. Card profiles may be combined.
E.2 Profile M
Cards of this profile have as a minimum the following features and commands.
--File structures
ù Transparent structure.
ù Linear structure with records of fixed lenqth
--Commands
ù READ BINARY and UPDATE BINARY with
P1. b8 = 0,
Lengths up to 256 bytes.
ù READ RECORD(S) and UPDATE RECORD with
P2, b8 to b4 = 0, P2, b3 = 1, P2, b3 b2 bl = 000, 001, 010 or 011 and P1 = 0
ù SELECT FILE with
P1 -P2 = '0000'
ù VERIFY with
P1-P2 = '0001' or '0002'.
ù INTERNAL AUTHENTICATE with
P1-P2 = '0000'.
E.3 Profile N
This profile is the same as M, plus the additional option P1 = '04' in the SELECT FILE command
!X E ative) :ard profiles
E.4 Profile O
Cards of this profile have as a minimum the following fe~tnre~ and ~ommand~
--File structures
ù Transparent structure.
ù Linear structure with records of fixed length.
ù Linear structure with records of variable length.
ù Cyclic structure with records of fixed length.
--Commands
ù READ BINARY, WRITE BINARY and UPDATF RI~I~Ry with
P1, b8 = 0,
Lenr~ths up to 256 bytes.
ù READ RECoRD(S), WRITE RECORD and UPDATE RECORD with P2, b8 to b4 = 0, P2, b3 = 1. P2. b3 b2 bl = 000. 001. 010 or 011 and P1 = 0.
ù APPEND RECORD with P1-P2 = '0000'.
ù SELECT FILE with P1 = '00', '01', '02', '03', '04', '08' or'09', P2 = '00'
ù VERIFY with P1-P2 = '0001' or '0002'.
ù INTERNAL AUTHENTICATE with p1 -P2 = '0000'
ù EXTE RNAL AUTH ENTICATE with P1-P2 = '0000'.
ù GET CHALLENGE with P1-P2 = '0000'.
ISO/IEC 781~4:1995 (E) E.5 Profile P
Cards of this profile have as a minimum the following features and commands.
--File structures
ù Transparent structure
--Historical bytes
ù Card service aata (= '3188').
ù Initial access data (= '4164').
--Commands
ù READ BINARY and UPDATE BINARY with
P1, b8 = 0,
Lengths up to 64 bytes.
ù SELECT FILE with
P1-P2 = '0400'.
ù VERIFY with
P1-P2 = '0001' or '0002'.
ù INTERNAL AUTHENTICATE with
P1-P2 = '0000'
~ISO/IEC E.6 Profile Q
Cards of this profile have as a minimum the following features and commands.
--Historical bytes
ù Initial access data (= '45'-GET).
ù Card capabilities (= '7180').
--Secure messaging --Commands
ù GET DATA and PUT DATA with
Tag in P1-P2,
ù SELECT FILE with
P1-P2= '0401, '0402' or'0403'.
ù VERIFY with
P1 = '00'.
ù INTERNAL AUTHENTICATE
ù EXTERNAL AUTHENTICATE
ù GET CHALLENGE
Ann (infor~ Use of secur F. 1 Abbreviations
For the purpose of this annex, the following abbreviations apply.
CC Cryptographic checksum CG Cryptogram CH Command header (CLA INS P1 P2) CR Control reference FR File reference KR Key reference L Length PB Padding bytes ('80' followed by 0 to k-1 times '00' where k is the block length) Pl Padding indicator byte PV Plain value RD Response descnptor T Tag 11 Concatenatlon
For all the examples, CLA indicates the use of secure messaging by an appropriate value ('0X', '8X', '9X' or 'AX'~ where bit b4 of CLA is set to 1 (see 5 41 and table 9).
F.2 Use of cryptographic checksums
The use of cryptographic checksums (see 5 6 3.1) is shown for the four cases defined in table 4 and figure 4
--Case 1--No data, no data Command data field = TCC ll LCC ll CC
Data covered by CC (b3=1 in CLA) = First and only data block = CH ll PB
The command of case 1 is transformed into a command of case 3
ex F ~ative) messaging --Case 2--No data, data Command data field = TCC ll LCC ll CC Data covered by CC (b3=1 in CLA) = First and only data block = CH ll PB Response data field = TPV (bl =1 ) ll Lpv ll PV ll TCC ll LCC ll CC Data covered by CC = Data blocks = TPV (bl =1 ) ll Lpv ll PV ll PB --Case 3.a--Data, no data Command data field = TPV (bl =1 ) ll Lpv ll PV ll TCC ll LCC ll CC Data covered by CC (b3=0 in CLA) = Data blocks = TPV (bl =1 ) ll Lpv ll PV ll PB --Case 3.b--Data, no data Command data field = TpV1 (bl=0) ll LPV1 ll PV1 ll TPV2 (bl=1) ll LpV2 ll PV2 ll TCC ll LCC ll CC Data covered by CC (b3=1 in CLA) = Data blocks = CH ll PB ll TPV2 (bl=1) ll LpV2 ll PV2 ll PB --Case 4--Data, data Command data field = TPV (bl =1 ) ll Lpv ll PV ll TCC ll LCC ll CC Data covered by CC (b3=0 in CLA) = Data blocks = TPV (bl=1) ll LYV ll PV ll PB Response data field = TPV (bl =1 ) ll LpV ll PV ll TCC ll LCC ll CC Data covered by CC = Data blocks = TPV (b1=1 ) ll Lr~v ll PV ll PB
ISO/IEC 7816-4:1995 ~E~ F.3 Use of cryptograms
The use of cryptograms (see 5.6.4) is shown with and without padding.
--Case a--Plain data not coded in EER-TLV Command data field = TCG 11 LCG 11 Pl 11 CG Data carried by CG = Data blocks = Non BER-TLV coded data and padding bytes, if indicated in Pl --Case b--Plain data coded in BER-TLV Command data field = TCG 11 LCG 11 CG
Data carried by CG = String of concealed bytes = BER-TLV data objects (padding depending on the algorithm and its mode of operation)
F.4 Use of control references The use of control references (see 5 6.5.1 ) is shown Command data field = TCR 11 LCR 11 CR Where CR = TFR 11 LFR 11 FR 11 TKR 11 LKR 11 KR
~ISO/IEC F.5 Use of response descriptor The use of response descriptor (see 5 6.5.2) is shown
Command data field = TRD 11 LRD 11 RD Where RD = TPV ll øø ll Tcc ll øø
Response data field = TPV 11 LPV 11 PV 11 TCC 11 LCC 11 CC F.6 Use of the ENVELOPE command
The use of the ENVELOPE command (see 7 2) is shown.
Command data field = TCG 11 LCG 11 Pl 11 CG
Data carried by CG = Command APDU starting by CH and padding bytes according to Pl
Response data field = TCG 11 LCG 11 Pl 11 CG
Data carried by CG = Response APDU and padding bytes according to Pl
ICS 35.240.40 Descriptors: data processing, information interchange, identification cards. IC cards, messages, security technlques, authenticanon Price based on 46 pages
[End raw scan]